[Octave-bug-tracker] [bug #53893] Rearranging widgets in the variable editor switches to another workspace

[Dan Sebald]

Follow-up Comment #17, bug #53893 (project octave):

OK, caught between the devil and the deep blue sea with another Qt issue then.
 I don't understand this bug, and I'm wondering if it is Unity related, just
like we saw issues with KDE Oxygen.  Here's the event processing, it's pretty
straightforward:


  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;
        bool retval = QDockWidget::event (event);
        if (isFloating ())
          emit queue_unfloat_float ();
        return retval;
      }

    return QDockWidget::event (event);
  }


It's basically a little state machine that watches for the user to move the
mouse and release the button.  This happens just after the widget is floated
(and the diff file I sent last time changed things so this state machine isn't
initiated).  If a mouse button press comes along before the button release,
the state is reset.  Similarly, in variable_dock_widget::toplevel_change(), if
the widget is redocked the state is reset.  I suppose there are a couple other
situations where the state could be reset for good measure.

I'm sure there is nothing in Qt documentation specifying exactly what sequence
of events happens with a toplevel-change.  So, I can understand there being a
bug in whether the widget ends up floating or not floating.

On the other hand, I can't figure out why this would have any influence on the
focus leaving for another application.  So, what happens if the state machine
complete's its sequence?  The following routine is *queued*:


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


setFloating() is a Qt method, so it should be robust in whatever window
manager it is working in.  Could doing this back-to-back setFloating() be a
bug in Unity?  If so, a solution might then be to issue the
"setFloating(false)" and then queue another slot that does the
"setFloating(true)".  (The same technique I've used quite often to avoid
similar issues.)

Torsten, I'm attaching a changeset that more thoroughly resets that state
machine, as I suggested above.  It may not fix anything, but give it a try and
see if it avoids the issue.  If you like, you may want to apply this patch in
any case; it's more thorough, I guess, and it will eventually come out because
it is conditionally included in compilation.

Otherwise, maybe the best thing is for me to install Ubuntu Unity here on some
hard drive.  (Exactly what version are you using?)  It would mean discarding
Kubuntu KDE Plasma, but KDE isn't something I use and I doubt I will look at
that Plasma Oxygen issue again, so no big deal.  It's just the process of
installing all the libraries again to make Octave build on Ubuntu Unity that
takes time.

(file #44231)
    _______________________________________________________

Additional Item Attachment:

File name: octave-more_thorough_variable_editor_state_reset-djs2018may27.txt
Size:1 KB


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?53893>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/