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: Mon, 19 Mar 2018 19:14:01 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0

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

Hi folks, sorry for the delay.  Over the weekend I cleared off a spare hard
drive and put Mint KDE/Plasma on it, because with tricky code like this there
is simply no way to do this via trial and error across the Internet. 
Basically I converted my machine to KDE so hadn't reliable access to email. 
After doing debugging on KDE I've created a new patch (attached) and now I'm
back on line, so to speak.

KDE definitely has a different focus scheme, but actually Qt doesn't say
anything about the focus events for a particular window manager, so I've had
to revisit, mainly, three or four issues which I will point out below.  I then
brought that changeset over to Mint Cinnamon and found a couple small, easy
issues which I fixed with queuing make_window() versus calling directly (don't
think they should have affected the KDE result any).

@Philip: Thanks for testing.  The Windows loss of float/unfloat button I don't
know about, but let's come back to that; it might resolve itself on its own. 
Yes, this is worth doing.  Keep in mind with something like this, one thing
off can make the whole thing kind of dodgy.  E.g., double-click doesn't
provide full decoration, so that puts things in an odd state making something
else fail, cascade of events, etc.

@Torsten: Comment #47, yes dropping the double-unparenting works; that simply
isn't documented behavior.  On KDE and Cinnamon, I now find that the rules Qt
describe do in fact apply as far as the parent rule and window decorations and
always-in-front.  However, this is one of the outstanding issues I had to
address on KDE because the sequence has to be very precise.  Here is the
"winning" formula:


    // the widget has to be reparented (parent = 0), preferably
    // from a non-toplevel widget otherwise may not have full
    // decorations, e.g., no taskbar icon and always in front
    setFloating (false);
// Remove after thorough testing 3/20/18    m_parent->removeDockWidget
(this);
    setParent (0, Qt::Window | Qt::CustomizeWindowHint | Qt::WindowTitleHint
|
               Qt::WindowMinMaxButtonsHint | Qt::WindowCloseButtonHint);


Without making sure that the QDockWidget is *not* floating first, there will
be full decoration window on KDE when the toplevel window is created, but it
will still remain "always-in-front" of the QMainWindow.  My thought is that
all Qt systems should now have the proper decorations (and we should be able
to drop that long tooltip about using <Alt>-left-button to move).  [The
unparenting line above seems unnecessary.  Probably done automatically.]

Going the other direction, from window to docked widget, is even trickier, and
this was one of the outstanding issues that I wish I'd realized from the
start.  Here's what the working version looks like:


    // Since floating widget has no parent, we have to read it
    QSettings *settings = resource_manager::get_settings ();

    settings->setValue ("MainWindow/windowState", m_parent->saveState ());
    // Stay window, otherwise will bounce back to window by default because
    // there is no layout information for this widget in the saved settings.
    setParent (m_parent, Qt::Window);
    m_parent->addDockWidget (m_recent_dock_area, this);
    // recover old window states, hide and re-show new added widget
    m_parent->restoreState (settings->value
("MainWindow/windowState").toByteArray ());
    setFloating (false);
    focus ();
    QApplication::setActiveWindow (this);
    show ();


I put a comment in there that we need to reparent the window, not only before
adding back to the QMainWindow, but *as a window*.  When the layout is saved,
there is no information about the window to be docked.  For that reason, when
it comes to restoreState() Qt doesn't know about that QDockWidget layout, so
its default is to set that QDockWidget to floating.  That's why I was often
seeing a window dock and then immediately undock...that is, it wasn't the OS
window-manager that was restricting this re-dock, just the Qt behavior because
of incomplete settings (maybe there's a better way).  Anyway, then *after* the
settings are restored, do a setFloating (false).

One other small detail (but improves things) is that I realized drag-and-drop
outside QMainWindow to cause float logic is already programmed into the
routine that highlights the title bar so rather than connect
make_window_on_one_focus_change() to QApp::focusChanged(), I connected it to
active_dock_changed().  Simple fix.

OK, so that left one more major issue, which was the really inconsistent
double-click to float/unfloat behavior.  Basically, there is no way to know 
after the fact that the toplevelChanged() came from a double-click as opposed
to any other route.  So I sought out as low-level routine as I could find, and
found there is a virtual QWidget::event() function which is analogous to the
eventFilter().  The following is new and is a means of tapping into low-level
event processing and determine if a docked widget became a floated window as a
result of a double-click:


  bool
  octave_dock_widget::event (QEvent *event)
  {
    // low-level check of whether docked-widget became a window via
double-click
    if (event->type () == QEvent::MouseButtonDblClick && ! isFloating ())
      {
        bool retval = QDockWidget::event (event);
        if (isFloating () && parent () != 0)
          {
            disconnect (m_parent, SIGNAL (active_dock_changed
(octave_dock_widget*,
                                                              
octave_dock_widget*)),
                        this, SLOT (make_window_on_one_focus_change
(octave_dock_widget*,
                                                                    
octave_dock_widget*)));
            emit queue_make_window ();
          }
        return retval;
      }

    return QDockWidget::event (event);
  }


So, give this latest patch a test.  I think it is much more robust now, and
hopefully the Windows issue of disabled float goes away.  If not, post a note.

(file #43597)
    _______________________________________________________

Additional Item Attachment:

File name: octave-float_as_toplevel-djs2018mar19.patch Size:38 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]