bugGNU Octave - Bugs: bug #53807, KDE QDockWIdget titlebar mouse...

 
 

bug #53807: KDE QDockWIdget titlebar mouse drag creates defective floated focus for Qt 5.3.2 -> 5.4.1

Submitter:  Dan Sebald <sebald>
Submitted:  Wed 02 May 2018 06:56:33 AM UTC
   
 
Category:  GUI Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Unexpected Error or Warning
Status:  None Assigned to:  None
Originator Name:  Open/Closed:  * Open
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Thu 03 May 2018 08:16:28 AM UTC, comment #2: 

The "work-around" for this one is in the patch for Bug #53276, i.e., https://savannah.gnu.org/support/download.php?file_id=44067

We could separate the code if this bug fix should be separate.  In any case, I'll give the bulk changes just to give an idea of the concept.  Basically, the code additions recognize when a drag-and-drop float occurs then immediately turns that window into a direct-floated window by docking and refloating.  The affect on appearance isn't too bad--just a momentary flash of the window.  (The title-bar-double-click and undock-button-press floats have no flash effect.)

Here are the main components:

From variable-editor.cc:


// See  Octave bug #53807 and https://bugreports.qt.io/browse/QTBUG-44813
#if (QT_VERSION >= 0x050302) && (QT_VERSION <= QTBUG_44813_FIX_VERSION)

  bool
  variable_dock_widget::event (QEvent *event)
  {
    // low-level check of whether docked-widget became a window via
    // via drag-and-drop
    if (event->type () == QEvent::MouseButtonPress)
      m_waiting_for_mouse_move = false;
    if (event->type () == QEvent::MouseMove && m_waiting_for_mouse_move)
      {
        m_waiting_for_mouse_move = false;
        m_waiting_for_mouse_button_release = true;
      }
    if (event->type () == QEvent::MouseButtonRelease && m_waiting_for_mouse_button_release)
      {
        m_waiting_for_mouse_button_release = false;
        m_waiting_for_activation_change = true;
      }
    if (event->type () == QEvent::ActivationChange && m_waiting_for_activation_change)
      {
        m_waiting_for_activation_change = false;
        bool retval = QDockWidget::event (event);
        if (isFloating ())
          {
            emit queue_unfloat_float ();
          }
        return retval;
      }

    return QDockWidget::event (event);
  }

  void
  variable_dock_widget::unfloat_float (void)
  {
    setFloating (false);
    setFloating (true);
  }
#else


and from variable-editor.h:


// See Octave bug #53807 and https://bugreports.qt.io/browse/QTBUG-44813
#define QTBUG_44813_FIX_VERSION 0x999999
  signals:

    void queue_unfloat_float (void);

  protected slots:

    void unfloat_float (void);

#if (QT_VERSION >= 0x050302) && (QT_VERSION <= QTBUG_44813_FIX_VERSION)
  protected:

    bool event (QEvent *event);

  private:

    bool m_waiting_for_mouse_move;

    bool m_waiting_for_mouse_button_release;

    bool m_waiting_for_activation_change;
#endif


The idea with this define:


#define QTBUG_44813_FIX_VERSION 0x999999


is to replace 0x999999 by the Qt version that fixes the problem.  In fact, I'm not sure the developers know exactly when the bug started, so even the lower limit of 0x050302 could have had its own definition.  Nonetheless, that's the point of it.

Dan Sebald <sebald>
Wed 02 May 2018 04:31:27 PM UTC, comment #1: 

Actually, this bug is unresolved as of now, so there is no upper limit on the QT_VERSION range as of yet.

Dan Sebald <sebald>
Wed 02 May 2018 06:56:33 AM UTC, original submission:  

I'm posting this bug report as a reference point to refer to in the C++ code.  I will have the workaround as part of the code associated with Bug #53276.  The code there is too fluid to be able to coordinate two separate changesets.

In debugging that Bug #53276 code on KDE, I ran into a puzzling issue in which only if I dragged a panel (QDockWidget) from the QMainWindow to float it did the focus behavior become corrupt.  Pressing on the title bar of the floated window would show the variable name in highlighted text and background for a fraction of a second and the focus would jump back to the main window.  Keep pressing the title bar and it was only momentary focus.  In other words, couldn't focus the floated window when floated by mouse drag.

With the QDockWidget in that state, I could click the tabs to make the Variable Editor and its floated dock widget hide.  Showing again would then have a correctly function focus behavior.  So, the fix appears to be hiding-then-showing the QDockWidget in that situation.  I had to do the hide and show as queued-connections in order to make the program flow go back to the system inbetween the hide and show.

I searched a long time for this bug, but then when I took away the custom title bar and used the default title bar, I knew straight away is was a Qt/KDE bug.  Searching the Internet I found a Qt bug report that is extremely close to what I described.  The Qt bug report is here:

https://bugreports.qt.io/browse/QTBUG-44813

That will at least give us another Qt bug in which we can use a version range to isolate the added kludge.

Can close as fixed since there isn't anything to discuss or code to patch, but I will post a code hunk to this report to illustrate the solution.

Dan Sebald <sebald>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by sebald (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    No changes have been made to this item

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code