[Octave-bug-tracker] [bug #53276] GUI: undocked panes cannot be moved, or resized along upper border

[Dan Sebald]

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

Whew, tricky stuff and lots of little details.  I have a changeset (see
attached), but it will probably need a small amount of adjustment based on
Torsten's feedback.  This is working pretty nicely on my system and I suspect
it should work well on most systems.

A short recap:  Recall the important quotes from the Qt documentation:

1) QDockWidget: "If a title bar widget is set, QDockWidget will not use native
window decorations when it is floated."

2) QWidget: "If parent is 0, the new widget becomes a window. If parent is
another widget, this widget becomes a child window inside parent. The new
widget is deleted when its parent is deleted."

3) "If the "new" parent widget is the old parent widget, this function does
nothing."

Based on the above statements, I conclude that we can't rely on this
construct:


    // remove parent and adjust the (un)dock icon
    setTitleBarWidget (0);
    setParent (0, Qt::Window | Qt::CustomizeWindowHint | Qt::WindowTitleHint
|
               Qt::WindowMinimizeButtonHint | Qt::WindowCloseButtonHint);
    setTitleBarWidget (m_title_widget);
    setParent (0, Qt::Window | Qt::CustomizeWindowHint | Qt::WindowTitleHint
|
               Qt::WindowMinimizeButtonHint | Qt::WindowCloseButtonHint);


Setting the parent to 0 twice in a row doesn't seem to have clarification in
the Qt documentation.  Is 0 considered a "parent widget"?  If so, then quote 3
above suggests nothing should happen with the second call to setParent().

I went down the path of trying to intercept system events in the event-filter,
but it just wasn't a reliable correlation with how Qt treated the event. 
E.g., "hide" and "hide-to-parent" events showed up in several instances.  It
just seemed to tricky.

It then seemed like we really didn't need the custom title bar, so my approach
was to try using the default title bar to avoid the vagaries across systems
possibly attribute to quote 1 above.  That seems to work pretty well, and the
title bar construct for the QDockWidget has been defined for quite a while. 
So stepping back and try to simply things slightly seems to work fairly well.

Some general comments that could possibly use feedback:

1) I tried maintaining the same flow in terms of make_window() and
make_widget() but now there is a lot of signal connection and disconnection
instead of the use of change_floating() and m_floating.

2) set_title() is still present, but now calling set_title() causes the custom
title bar to be used.  I switched all of the octave_dock_widget inheritors to
call setWindowTitle() instead, which then uses default title bar.

3) With default title bar, the icons and tooltips are all controlled via the
cascading style sheets.  One might notice that the label in the default title
bar is a tad further left than the custom title bar, but that could possibly
be adjusted via the CSS.

4) No custom title bar means not having to call setParent(0,...) twice in a
row.  However, I did notice that there is something undesirable about setting
the parent to 0 when the QMainWindow has already floated the widget--no
taskbar entry and the window stays in front of parent.  So, in make_window()
I've added setFloating() and removeDockWidget() just to cover all bases:


    // 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);
    m_parent->removeDockWidget (this);
    setParent (0, Qt::Window);


and at the end of make_window() I've added:


    raise ();
    show ();
    activateWindow ();


to get that window to the front.

5) For make_widget(), the reparenting didn't seem a necessary step.  Just
m_parent->addDockWidget() enough.  But I did leave a commented out line of
code where the reparent should be done, anticipating that this might not work
exactly right on some systems.

6) I reinstated the full features of float and close, so now dragging the
title bar off of the QMainWindow will make it a toplevel parent and I figured
out a way of recognizing this was done after the "drop" was done and queued a
make_window().  Otherwise, calling make_window() as soon as a title-bar drag
is done will crash.

7) I did disable title-bar double-click float in the event-filter, though. 
The problem was that double-click float didn't go the route of the re-defined
default float button so wouldn't create a toplevel window.  We could probably
figure out a way to queue some kind of check on whether the widget was made
toplevel and convert it via make_window()...similar to 6 above.  Or maybe put
a QAction on the float button that is tied to the title bar double-click
somehow.  This feature doesn't exist in the current system though, and perhaps
everyone is fine with that.

8) This default title bar approach works well here.  But when said-and-done, I
tried the custom title bar as well and that too produces full-decoration
floated windows.  None-the-less, all the major octave_dock_widget inheritors
are now default title bar based because I suspect the custom option wouldn't
work, such as in Philip's case.  (The variable editor panels still use custom
title bar to get the third "fullscreen" button.)  Experiment if you like. 
Perhaps something I've done in 4 above was the ultimate fix.

9) I slightly changed the way current geometry is tracked, because it seemed
more convenient to have the whole geometry info at hand rather than use the
settings as an intermediary.  There is now a

m_recent_float_geom
m_recent_dock_area
m_recent_dock_geom

that are updated with every move and resize event.  Those are used when saving
info to settings.  The consequence is that now the only time this information
is saved is when exiting.  If there is a crash, the info is lost.  However, it
is an easy matter to call octave_dock_widget::save_settings at any pointed
desired.  So add that call if it is desired to save at time of conversion
to/from floated windows.  I felt calling save_settings every time there is a
resize or move is too much because drag-moving a window then gets to be too
much disk/sync activity.

10) As a consequence of 9, I had to move settings_changed() before
set_window_layout() in main-window.cc:


+    emit settings_changed (settings);
+
     set_window_layout (settings);


It doesn't matter to me, but it is a matter of whether settings_changed should
be active or passive.  I can change it so that settings_changed will not only
update

m_recent_float_geom
m_recent_dock_area
m_recent_dock_geom

but also readjust the windows, in which case set_window_layout() will set the
floated window geometry once and settings_changed() also a second time.

(file #43547)
    _______________________________________________________

Additional Item Attachment:

File name: octave-float_as_toplevel-djs2018mar14.patch Size:34 KB


    _______________________________________________________

Reply to this item at:

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

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