ok I missed it :)

I didn't get around to trying the latest, but I am assuming the comment #36: the editor doesn't update the Windows menu when closing via the window close button is still valid and should be added to a new bug report ?

We closed this report, but what to do with the dock/undock shortcuts? (Dan's Easter egg patch in comment #14)
New report / feature request?

@Philip comment #49

The Qt::window flag that Dan has removed was there for a very long time (several years?).

@Dan comment #46:
I wouldn't call Qt "nuanced" but rather "fragile" code. Maybe even extremely fragile, judging from that just one tiny condition in some sort of logical statement makes so much difference.
I also wonder where that condition came from (which changeset introduced it). Maybe we'd better track back to it, undo all related fixes postdating it and only leave out that condition? If all that code in the related fixes doesn't hurt, well OK, but I get an itchy feeling that we're not sure what these fixes really do nor what side effects they may have.

BTW I didn't even try fresh clones of mxe-octave and octave, just the local branch I have been using for the last 1.5 month or so.
That is fairly clean anyway, as I usually start a new local branch about every 6-8 weeks based on the then current dev branch and apply my favorite patches to it.

BTW status => Ready for test - hopefully another dev can confirm the fix.

Very good! Thanks for testing and for the additional patch. I would like to push the cset of comment #26 togehter with Dan's patch since the former is required for my upcoming patch for bug #53712.

Your patch in comment #41 finally did it Dan. Good work!

I applied it on top of the one in comment #26. Now I'm wondering if that one is still required - although it doesn't seem to hurt :-)

Patch of comment #41 on top of the one from comment #26, or stand-alone?

I'll also start with fresh mxe & octave clones, just to be sure I have no cruft lying around.

So, this isn't quite a fix then?  Hmm... here are links to the Qt source code:

https://code.woboq.org/qt5/qtbase/src/widgets/widgets/qdockwidget.cpp.html#_ZN18QDockWidgetPrivate13updateButtonsEv

https://code.woboq.org/qt5/qtbase/src/widgets/widgets/qdockwidget.cpp.html#_ZNK17QDockWidgetLayout16nativeWindowDecoEv

https://code.woboq.org/qt5/qtbase/src/widgets/widgets/qdockwidget.cpp.html#_ZN11QDockWidget10paintEventEP11QPaintEvent

Regardless of this patch or the original problem for the builtin toolbar, based on the code it seems that if there is native decorations then there is no QDockWidget title bar.  I.e.,

    bool customTitleBar = layout->widgetForRole(QDockWidgetLayout::TitleBar) != 0;
    bool nativeDeco = layout->nativeWindowDeco();

    if (!nativeDeco && !customTitleBar) {
[snip]
    }

There may be a subtle distinction on exactly how the Window window needs to be floated, e.g., don't remove it as a child of the QMainWindow or something like that.  Here's the Qt code definition of what it means to be a window

bool QWidget::isWindow() const
/*!
    \fn bool QWidget::isWindow() const

    Returns \c true if the widget is an independent window, otherwise
    returns \c false.

    A window is a widget that isn't visually the child of any other
    widget and that usually has a frame and a
    \l{QWidget::setWindowTitle()}{window title}.

    A window can have a \l{QWidget::parentWidget()}{parent widget}.
    It will then be grouped with its parent and deleted when the
    parent is deleted, minimized when the parent is minimized etc. If
    supported by the window manager, it will also have a common
    taskbar entry with its parent.

    QDialog and QMainWindow widgets are by default windows, even if a
    parent widget is specified in the constructor. This behavior is
    specified by the Qt::Window flag.

    \sa window(), isModal(), parentWidget()
*/ ↪

Ah, there is something at the end there about the Qt::Window flag.  Perhaps that needs to be cleared, i.e., parent=0 but also Qt::Window flag is false.  Just guessing.

Does my patch really change the behavior of the VE subpanes? This would be very surprising.

Regarding the still missing "inner" title bars, I have also pulled recent updates into my mxe build environment yesterday (Qt 5.11) and have tested on Windows 7. Does anyone has an idea about what else might make a difference here?

Confirmed comment #32 and comment #36 on Ubuntu. I will file a spearate bug for this.

Perhaps ignore comment #33, as when I deleted the .config dir, the window stopped undocking somewhere offscreen.

And not sure if related, but when dragging the variable window out to undock it is removed from the main window but I think is showing up somewhere off screen.

In Windows window managers are extremely rarely used (they do exist). However themes can be set but AFAIK those don't mess with toolbar presence.

Sure I'll have a look, tonight or tomorrow night.

As to double clickto doc/undock:
In Windows, double-clicking the title bar of a docked pane will undock it. But double-clicking the title bar of an undocked pane will maximize the pane window, as expected by many many Windows users. So I think double-clicking a title bar is not the way to go as far as Windows is concerned.

If there's no way to set the dock state in the main GUI's Window menu, I'm in favor of somehow pimping Dan's easter egg patch of comment #14 into something that has configurable shortcuts.

For me, I was planning to get some sort of Windows build working so that I could analyze directly without guessing what might fix this.  (However, I've been too busy this summer to work on doing that.)

I've applied the patch you tried and compiled...and recompiled to make sure the version I was testing is the one that is modified by the patch.  It seems to work fine and the same in Linux Mint/Cinnamon before and after the patch, which really confuses me.  The double click to float and redock still is fine.  I would think that double-click doesn't do anything when there is a custom title bar--I don't see any specific code programmed into the custom title bar to do that, so it must be the underlying Qt code that still allows it.

Recall way back all these issues with losing the native window manager decorations?  Perhaps we got so wrapped up in dealing with that that we didn't think to check and realize the custom title bar will still allow drag and double-click operations from the QDockWidget perspective.

If this patch works for KDE Plasma, barring Oxygen, I'm fine with it.  It is certainly the easiest way to deal with Windows without seemingly altering Linux implementations.

... file attached.

(file #44370)

@Dan:
The "Easter Egg" patch in comment #14 works fine, thanks very much.

The shortcut key sequences:

Those would be available in both Windows and Linux.  They're convenient, but the issue is how to make the user aware of them.  The existence of shortcuts associated with a drop down menu can be gleaned from listing right next to the action.  The shortcuts of the

https://savannah.gnu.org/bugs/download.php?file_id=44348

patch are of the "easter egg" variety with no documentation.  And I made them sort of complex so there is no accidentally typing them.

As Philip said, a documented command for dock/undock is the easier way for the user to at least having a chance of finding some alternate route of dock/undock.  The problem there is defining something logical

dock "Variable Editor"
dock "Command Window"
etc.

?????

Plus, the command-line interaction requires programmers to delve in the libinterp/corefcn/octave-link.cc code, which isn't something I want to do.  I wish that were programmed differently so that the GUI could override the behavior of functions.  I don't like GUI-specific in the core code.

I was thinking last night that perhaps the dock/undock could be mixed in with the Window drop-down menu.  Notice how things like

File:New
File:Recent Editor Files
Help:Documentation

have a little triangle next to them, which when followed with the mouse presents a submenu?  We could do the same thing with

Window : Command Window > Show Ctrl+Shift+0
                          Hide
                          Dock
                          Undock

where the column to the right is meant to represent the submenu created by dragging the mouse over the tiny triangle.

BTW, I'm a bit confused by the current Window drop-down menu.  In the attached screenshot notice there is a Show WINDOW list and below that is a WINDOW list.  Are these pretty much the same thing?  (If WINDOW is selected it also shows the window.)  Or does one just show and hide while the bottom one will focus as well?  That seems like a fairly big additional list in the drop-down menu for splitting hairs.  Furthermore, I wonder how many people are going to remember the number and association with a window.  That is Cntrl+Shift... +3, that "3" part isn't something I would remember.  I typically associate a letter in some way, e.g., the first or second letter of the name of the object.  Plus, acting on the current window is useful, e.g., "dock the currently focused window", that sort of thing.  And there are probably ways of generating a context menu, e.g., I type Cntrl+Shift and it pops up a menu with a list of windows to select from.

With the diff in comment #13 I now see this:

• Undocked panes no longer have a title bar. That title bar could be used to drag the pane around on the desktop, so dragging is no more possible.

• Double-clicking the title bar now works for docking / undocking. For undocked panes there's no more way to maximize the  pane to full desktop  / minize to taskbar button/ restore pane size.

• Undocked panes have a toolbar with a working "dock" button.

• The undocked Variable Editor pane can be right-clicked to get a command "Variable editor toolbar" that works to enable/disable the toolbar.

• Undocked panes have no clear border indicating where the "grip are" is for resizing panes. Before the patch the cursor changed shape into a proper resize cursor. With the patch it doesn't change. Attached is a photo of the screen (can't take screen shot as then the cursor is hidden) where the cursor is in the lower right position to resize the screen.

Similarly to the latter bullet's contents, there are no visible borders between docked panes to make it easy to target the mouse cursor position for resizing panes (but that is already a long time). See 2nd & 3rd attached pic, also photographs, where the invisible border between workspace and variable editor is only indicated by the resize cursor (cursor does change for undocked panes) in an otherwise completely flat gray area.

(Sorry for the moiré in the last ics, unavoidable when making photos from PC screens.)

FYI I've applied the comment # 13 patch right after updating the Dan's mega patch from 5 weeks back.
(Remarkable that such a tiny patch can make so much functional visual difference)

Torsten wrote: "Is 05a690606fd5 the big changeset from a month and a half ago?"

Well 05a690606fd5 is just prior to a recent change.  3764ebd3b589 is prior to the big changeset.  So if Windows 7 works fine for 3764ebd3b589 and not for 05a690606fd5 then it is the big changeset that is responsible.

The reason for going back to the default title bar is because of the loss of window decorations, i.e., the Window Manager's frame, for more than KDE Oxygen.  I experienced loss of decorations in linux Mint/Cinnamon, in the sense that Mint/Cinnamon was following the rules set down by the documentation.  That is, the documentation states:

http://doc.qt.io/qt-5/qdockwidget.html#setTitleBarWidget

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

KDE Oxygen is missing the decorations in any case.  (Not our responsibility.)  Because the documentation indicates so, I suspect that Windows 7 also loses the window decorations if the custom title bar is used.

Reply to comment #13

I'm attaching a diff file that will restore the custom header file. Of course, we already know on linux such a change will mean we get no decorations (that's Qt documentation).

As far as I remember this only happened on KDE Oxygen?

I suspect this will be a bug we have to live with on Windows 7

I think, losing the dock/undock buttons in Windows (possibly other versions aside from 7 are also affected) is not a bug we should tolerate.

OK.  So some more trial and error for a work-around.  :-)

I'm attaching a diff file that will restore the custom header file.  Of course, we already know on linux such a change will mean we get no decorations (that's Qt documentation).  Could you see if the same thing happens for Windows 7?  I.e., that the decorations are lost and you are unable to move/resize/minimize the window?  I suspect that will be the case.  If not, then I can add a double click to the custom title bar to unfloat (dock).

I suspect this will be a bug we have to live with on Windows 7.  Although, this bug could be tolerable if we add instead of some button, maybe a shortcut key like Cntl-D that means "dock".  Oh, wait a second, those buttons are actually implemented via an action--which I think is specifically created by Qt for the purpose of unifying the "action" short-cuts.  Sure:

http://doc.qt.io/qt-5/qaction.html#shortcut-prop

that would be an easy addition.  I'll make a separate diff file for that idea, otherwise it will get confusing.

(file #44342)

Again, I suggest some dock/undock option in the Main menu window submenu (see bottom of comment #6). That might also be more independent of Qt window pane decoration bugs.

(Title adapted)

may have not used the GUI in Windows 7 for a while
Au contraire, I only use the GUI, never the CLI, but I don't often undock the VE and I have the editor always undocked (and on another monitor). IOW the layout I use is fairly static. Plus I use octave on about 5 or 6 PC's and lately I've been a bit lax about updating my Octave installations. Little wonder I didn't note earlier ;-)

Anyway, is the culprit just a missing dock button, or an entire missing title bar as Torsten noted?
If it's the latter I'd better adapt the bug report title.

@Dan:
I don't know how often we can keep putting in work-arounds for Qt bugs.
Indeed, reading back in the various Qt-related bug reports it seems Qt is a continuous story of version-specific workarounds.
Maybe we want just too much from Qt and we'd better dim or ambitions a little :-)

But that said, I am very happy with the GUI's capabilities, esp. the floating VE subpanes. It makes my work a lot easier than when just using a CLI as in the old days.

Philip, I was referring to the octave gui preference of using a custom color scheme for (settings dialog, "Gerenal" tab).

@Torsten:
Remember this is Windows, there's not much of a theme that pervades as much as on linux. That said I have the "Windows Classic" theme on these Windows 7 boxes.

Some other observations (see next screenshot):
After the commands a = rand(3) and b =  and (3), opening them both in the VE, and clicking one of the inner undocking buttons, I get the pic in the first attached screenshot. One can see that there's not much of a clear separation between the subpanes in the (docked) VE panel.

(That is a more generally valid observation - vertically arranged subpanes have no clear separation at all on Windows; to resize docked panes that are above each other one has to slowly move the mouse cursor until -somewhere in the middle of the gray area between the panes- it changes shape into a drag type cursor . No big deal, but not beautiful or helpful for novice Octave users)

Then, after undocking the VE with the "outer" VE undock button (looking like a "maximize" button), the pane with the docked subpanel moves out of the main GUI window but the "undocked" subpane stays inside (!). Only after clicking it's dock button [*] it moves into the undocked VE pane.

[*] I Didn't note it first but it is undocked main GUI panes that lack a "dock" button. Undocked VE subpanes from undocked VE panel still have it. See the second pic, where I undocked just one subpanel. Does that answer your question Dan?


If you want to experiment yourself, I've uploaded a mxe crossbuilt installer (64b-idx 5.0.0) from the day before yesterday here to save you the time for crossbuilding:
https://prn183.stackstorage.com/s/O8Oy9FGlOK6V7YA
(link valid until June 15)
Don't get distracted by some local mods (uitable & h5read patches from the patch tracker that I keep "alive" + some smaller patches)

Strange.  I'm not seeing any issues in linux.  Although there has been activity around the V.E. and floated/unfloated windows, it's more to do with the actions, shortcuts and working-around Qt bugs.  There hasn't been much to do with the octave_dock_widget layout for quite a while.  Can you guess about when this started happening?  There is one changeset that may have inadvertently affected this:

http://hg.savannah.gnu.org/hgweb/octave/rev/9b67c2294129

Maybe the "set_style(true)" has something to do with it, but that's just a guess.  We should really do a bisect.

BTW, the screenshot you posted suggests it is the octave_dock_widget that is missing the title bar.  Recall, that is now back to the default title bar.  Qt documentation indicates there is no way of removing the title bar, but the effect can be achieved by using a custom title bar that is an empty widget.

octave_dock_widgets cannot be dragged back into the GUI as a means of redocking.  Recall that the process of floating an octave_dock_widget does some steps to make the window a top level window.  It's no longer a QDockWidget in the conventional sense.  So it is not just Windows in which one can't redock an octave_dock_widget by dragging.

How about the variable_dock_widgets?  Are you seeing a title bar in that case?  The variable_dock_widgets are the floatable subpanels (the individual variables) of the V.E.  The variable_dock_widget uses the custom title bar and remains as a QDockWidget (i.e., no full decorations), so those should be dockable.