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

[Dan Sebald]

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

OK, the screen shot has helped, I think.  I understand now that you are
referring to Octave GUI's main window.  I originally thought that you were
referring to the variable editor undocked panels.  If for the latest version
you could test somehow, e.g.,

x = eye(5);
openvar x;

whether the variable-editor panel can be moved via the title, that would be
useful to know.  (I suspect it might be movable.)

Back to the screen shot.  Notice that the title bar in the variable editor and
text editor (behind the main GUI) is only the custom one, i.e.,


-------------------------------
octave's added label line
-------------------------------


content


-------------------------------


So it is the scenario Torsten described for KDE, discussed more here:

https://savannah.gnu.org/bugs/?53275#comment11
https://savannah.gnu.org/bugs/?53275#comment13

Right now, my thought is that peculiar sequence of removing the title bar,
unparenting, restoring the title bar and unparenting is an undocumented
behavior (i.e., just happens to work for some strange reason in KDE).  I
assume that when the changeset is backed out the blue window-manager frame is
present similar to the main Octave GUI window.

I'm attaching a simple diff patch file for you to test and see if it restores
the window-manager decorations for you.  All it does is leave the custom title
bar off and then unparent.  If that does work for you, then what we might be
able to do is when switching to undocked mode, make the current custom toolbar
simply a static widget just below the window-manager's title bar.  

My thinking is that the undocumented behavior (or Qt bug, or whatever one
wants to call it) is unparenting (i.e., top-level) when there is a custom
title bar present.  I've seen the following two statements in 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."

In Cinnamon, I know that rule 1 is being followed in the variable editor;
that's why I had to add a frame to the panels:

https://savannah.gnu.org/bugs/?53275#comment15

We also see that rule 2 is being followed by both KDE and Cinnamon because all
of the main octave_dock_widgets based off the main panel are becoming toplevel
windows.  However, there seems to be some question or consistency issues about
what exactly happens when both those conditions are present.  (And no
statement in Qt documentation regarding this...it could be a bug that Cinnamon
still has decorations present, or a but that KDE doesn't have decorations
present.)  If we can avoid the scenario, maybe that is best, at least for now.

(file #43494)
    _______________________________________________________

Additional Item Attachment:

File name: check_if_no_custom_titlebar_works_in_kde_djs2018mar08.diff Size:0
KB


    _______________________________________________________

Reply to this item at:

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

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