octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #53276] GUI: undocked panes cannot be moved, o


From: Dan Sebald
Subject: [Octave-bug-tracker] [bug #53276] GUI: undocked panes cannot be moved, or resized along upper border
Date: Tue, 3 Apr 2018 17:03:56 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0

Follow-up Comment #69, bug #53276 (project octave):

I'm attaching a new patch with a slight modification to the "toplevel window
via drag-and-drop" algorithm.  The reason for this was the not-quite-correct
behavior when using main_window::focus_changed().  See here

http://savannah.gnu.org/bugs/?53537

So rather than pin the toplevel-change on focus behavior, I looked for an
event that correlates with drop outside the main window versus drop inside the
main window.  I whittled all the observed event codes down to
QEvent::ActivationChange.

So the basic change is an additional conditional in the event handler:


  bool
  octave_dock_widget::event (QEvent *event)
  {
    // low-level check of whether docked-widget became a window via
    // double-click or via drag-and-drop
    if ((event->type () == QEvent::MouseButtonDblClick && ! isFloating ())
        || (event->type () == QEvent::ActivationChange &&
m_waiting_for_mouse_button_release))
      {
        bool retval = QDockWidget::event (event);
        if (isFloating () && parent () != 0)
          {
            m_waiting_for_mouse_button_release = false;
            emit queue_make_window ();
          }
        return retval;
      }

    return QDockWidget::event (event);
  }


i.e., (event->type () == QEvent::ActivationChange &&
m_waiting_for_mouse_button_release) where m_waiting_for_mouse_button_release
takes the place of the active_dock_changed() signal connection.

This works very nicely for me in both Cinnamon, Qt 5.5.1-4ubuntu3 and
KDE-Plasma, Qt 5.6.1-2build1~~xenial (the problematic one).

@Philip: The current tip of either stable or default, e.g.,

http://hg.savannah.gnu.org/hgweb/octave/rev/1fdd1b211ed4

should have the bug fixes meant to address the Qt bug.  You should first build
and test that on Mageia 6 Plasma/KDE, Qt 5.6.2.  That will be your reference
point, as I don't think there is much more we can do for the Qt range of 5.6.1
to 5.7.1-.  Rik doesn't have movable windows in his version of Mint KDE/Plasma
with Qt 5.6.1; I do.  I think it may have something to do with the way the
desktop coordinates are set, e.g., multiscreen system, that sort of thing.  If
you are unable to move widgets and/or windows with that base reference, then I
think we'll have to find someone with Qt 5.7.1 or greater and write other
problems off to the Qt bug if the latest versions work.

I do sometimes see strange behavior similar to what you described with the
Variable Editor panels--if I have the floated variable panel too big,
sometimes it won't re-dock in the position I try, but then I just drop it
somewhere within the Variable Editor, grab the window again and then it
repositions fine.



(file #43790)
    _______________________________________________________

Additional Item Attachment:

File name: octave-float_as_toplevel-djs2018apr03.patch Size:37 KB


    _______________________________________________________

Reply to this item at:

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

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]