bugGNU Octave - Bugs: bug #54078, No more QDockWidget title bar and...


bug #54078: No more QDockWidget title bar and dock button on undocked panes under Windows

Submitted by:  Philip Nienhuis <philipnienhuis>
Submitted on:  Thu 07 Jun 2018 09:03:21 AM UTC  
Category:  GUI Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Regression
Status:  Fixed Assigned to:  None
Originator Name:  philipnienhuis Open/Closed:  Closed
Release:  dev Operating System:  Microsoft Windows

Add a New Comment (Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


( Jump to the original submission)

Wed 27 Jun 2018 08:52:04 PM UTC, comment #57: 

ok I missed it :)

John Donoghue <lostbard>
Project Member
Wed 27 Jun 2018 08:42:07 PM UTC, comment #56: 

I have already filed a new bug report for this issue (bug #54185).

Torsten Lilge <ttl>
Project Member
Wed 27 Jun 2018 08:40:06 PM UTC, comment #55: 

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 ?

John Donoghue <lostbard>
Project Member
Wed 27 Jun 2018 07:24:19 PM UTC, comment #54: 

I have created a new report (bug #54198)

Torsten Lilge <ttl>
Project Member
Wed 27 Jun 2018 06:48:38 AM UTC, comment #53: 

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 Nienhuis <philipnienhuis>
Project Member
Tue 26 Jun 2018 08:51:55 PM UTC, comment #52: 

I here what you are saying.  I too went back through the changesets to see if that setting had changed in recent months, but it seems it didn't.  Parent zero or nonzero, window flag set or not set, a few other settings--that's what I meant by nuanced.  I suspect years ago those who managed to get the decorations to appear were just happy enough to achieve that at that point.

Dan Sebald <sebald>
Tue 26 Jun 2018 08:42:49 PM UTC, comment #51: 

@Philip comment #49

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

Torsten Lilge <ttl>
Project Member
Tue 26 Jun 2018 08:14:07 PM UTC, comment #50: 

Our posts crossed.
I'll reset status to "fixed". Thanks!

Philip Nienhuis <philipnienhuis>
Project Member
Tue 26 Jun 2018 08:12:52 PM UTC, comment #49: 

@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.

Philip Nienhuis <philipnienhuis>
Project Member
Tue 26 Jun 2018 08:00:57 PM UTC, comment #48: 

Pushed with csets

Closing the report. If there is an issue showing up later, we can reopen it.

Torsten Lilge <ttl>
Project Member
Tue 26 Jun 2018 07:37:30 PM UTC, comment #47: 

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.

Torsten Lilge <ttl>
Project Member
Tue 26 Jun 2018 07:24:05 PM UTC, comment #46: 

Oh, what good news!  :-)  Qt is such nuanced code.  I wouldn't have guessed that mattered without having looked at the source.

As with the Comment #26 changes, this one-line change doesn't seem to affect the behavior in Linux.  If there is some version of Linux for which it matters, we can conditionally compile based on Window/Linux.

Thanks for testing.

Dan Sebald <sebald>
Tue 26 Jun 2018 07:07:18 PM UTC, comment #45: 

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 :-)

Philip Nienhuis <philipnienhuis>
Project Member
Tue 26 Jun 2018 07:04:15 AM UTC, comment #44: 

All alone and/or with Torsten's changes.

Dan Sebald <sebald>
Tue 26 Jun 2018 06:52:19 AM UTC, comment #43: 

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.

Philip Nienhuis <philipnienhuis>
Project Member
Mon 25 Jun 2018 09:17:35 PM UTC, comment #42: 

Please try this simple changeset to see if it makes a difference on Windows.

(file #44439)

Dan Sebald <sebald>
Mon 25 Jun 2018 08:57:01 PM UTC, comment #41: 

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




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) {

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.

Dan Sebald <sebald>
Mon 25 Jun 2018 08:41:47 PM UTC, comment #40: 

I was using windows 10, Qt 5.11, 64bit with patch from comment #26.

Attached pic docked vs undocked var editor for me

John Donoghue <lostbard>
Project Member
Mon 25 Jun 2018 08:27:09 PM UTC, comment #39: 

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?

Torsten Lilge <ttl>
Project Member
Mon 25 Jun 2018 07:49:00 PM UTC, comment #38: 

What I see on Windows 7 with the patch from comment #26 is that V.E. SUBpanes have a complete QDockWidget toolbar with an undock button. I can undock V.E. subpanes from a docked V.E. pane (see attached pic) and they have a dock button, but the undocked "main V.E. pane", still has no dock button, nor e.g., the undocked editor.

At least this goes some way in the right direction :-)

My mxe-octave build tree has Qt 5.11

Philip Nienhuis <philipnienhuis>
Project Member
Mon 25 Jun 2018 07:36:28 PM UTC, comment #37: 

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

Torsten Lilge <ttl>
Project Member
Mon 25 Jun 2018 07:16:21 PM UTC, comment #36: 

For comment 32, the editor is the only one that doesn't update the Windows menu when closing via the window close button.

John Donoghue <lostbard>
Project Member
Mon 25 Jun 2018 07:11:58 PM UTC, comment #35: 

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

John Donoghue <lostbard>
Project Member
Mon 25 Jun 2018 07:08:02 PM UTC, comment #34: 

Comment #33: Does this happen when the V.E. window is first floated by clicking the undock button?  Drag-and-drop should restore the previous position regardless of where the drop is done.  Perhaps there is some invalid position at the start.

Dan Sebald <sebald>
Mon 25 Jun 2018 07:03:50 PM UTC, comment #33: 

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.

John Donoghue <lostbard>
Project Member
Mon 25 Jun 2018 07:00:41 PM UTC, comment #32: 

On my new windows build, I see the doc/close widget with this patch applied. Both normally and when undocked.

And double clicking on the dock widget part of the titlebar will dock and undock it.

I think the only missing thing I see on mine is that when closing the undocked window using the windows (not toolbar) close button the window will close however the Window menu doesn't update its state.

John Donoghue <lostbard>
Project Member
Mon 25 Jun 2018 06:08:27 PM UTC, comment #31: 

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.

Philip Nienhuis <philipnienhuis>
Project Member
Mon 25 Jun 2018 05:54:40 PM UTC, comment #30: 

I meant double clicking the QDockWidget (custom) title bar to undock/dock.  The window manager's title bar should behave however the window manager wants it to.

window manager title bar
QDockWidget title bar

I believe right now the QDockWidget title bar is missing from your Windows build when the octave-dock-widgets are floating.

The shortcuts:  Even outside of being an escape route when the window is missing decorations, they are nice to have.  Something like in comment #22 is good.  However, Torsten perhaps it is a good idea to survey the discussion list for an implementation because people like M.M. are really up on what is sort of "standardized" or common U.I. actions.  Also, raise the topic of using numbers (e.g., Ctrl+Shift+0) versus some other better memory/association aid.

Dan Sebald <sebald>
Mon 25 Jun 2018 05:42:09 PM UTC, comment #29: 

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.

Philip Nienhuis <philipnienhuis>
Project Member
Mon 25 Jun 2018 05:05:36 AM UTC, comment #28: 

Philip, could you then please test the patch on your windows systems, if it fixes the issue?

Torsten Lilge <ttl>
Project Member
Sun 24 Jun 2018 11:48:00 PM UTC, comment #27: 

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.

Dan Sebald <sebald>
Sun 24 Jun 2018 08:11:07 PM UTC, comment #26: 

What the current state of this report?

While working on bug #53712, i.e. using an QMdiArea for the editor sub windows, it turned out that re-styling the editor window when losing focus again gives focus to the editor when the mdi area uses tabbed viewing with maximized sub windows. I really do not get the relation but this issue disapperes when using the custom title bar widget again.

In addition, this also seems to fix this bug #bug #54078, at least on my Windows 7. Even on KDE the window decoration seems to be complete.

Please find attached the related patch.

(file #44424)

Torsten Lilge <ttl>
Project Member
Thu 14 Jun 2018 09:52:31 PM UTC, comment #25: 

... file attached.

(file #44370)

Dan Sebald <sebald>
Thu 14 Jun 2018 09:50:04 PM UTC, comment #24: 

I posted this issue to the discussion list and the missing title bar continues out to Qt 5.11.  That fact more than likely means this is not a Qt problem.  Also, for the record the tester found that the attached patch did not resolve anything.

So, I'll keep thinking about this one.

Nonetheless, it may be a good idea to implement shortcuts via drop down menu that was discussed in Comment #21 to Comment #23.  Dock/Undock/Hide/Show shortcuts seems a convenient thing to have.

Dan Sebald <sebald>
Tue 12 Jun 2018 06:04:42 PM UTC, comment #23: 

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

Philip Nienhuis <philipnienhuis>
Project Member
Mon 11 Jun 2018 05:47:37 PM UTC, comment #22: 

I like the

Window : Command Window > Show Ctrl+Shift+0


AFAICS in the current Window menu, "Show Command window" merely unhides a pane (and probably transfers focus to it, I can't definitely assess), and "Command window" by itself merely gives focus to the pane. The latter menu option looks a bit superfluous to me but there may be a good reason for it.

I agree that docking / undocking could be done by focusing or clicking on a pane and then type some general dock/undock shortcut; maybe one and the same key combo that docks when the pane is undocked and vice-versa. Or maybe even also RMB on the pane's toolbar/title bar with a pop-up could do that.
First focusing or clicking on the pane resembles Matlab's way where a pane is docked/undocked by dragging it into/out of the main GUI.

Philip Nienhuis <philipnienhuis>
Project Member
Sun 10 Jun 2018 05:51:50 PM UTC, comment #21: 

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


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"


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:Recent Editor Files

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

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.

Dan Sebald <sebald>
Sun 10 Jun 2018 05:06:28 PM UTC, comment #20: 

@Philip wrote: "Undocked panes no longer have a title bar."

I assume you meant "Window Manager title bar".  Yeah, well that's according to Qt documentation, so no surprise there.

@Philip wrote: "there are no visible borders between docked panes to make it easy to target"

I suppose this is a consequence of having no decorations when transitioning back to the docked state.  But in light of the first point, this one is ancillary.

Qt is at 5.11 series now.  I think at the moment the best thing is to open this to the discussion list and find out if there is someone using 5.8 or higher.  I've searched Qt's bug list and can't find much about this, and although there are plenty of QDockWidget bug reports, other than those two I listed below I can't find a close match.  One would think a bug of this severity would have been reported somewhere.

Dan Sebald <sebald>
Sun 10 Jun 2018 11:01:13 AM UTC, comment #19: 

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)

Philip Nienhuis <philipnienhuis>
Project Member
Sun 10 Jun 2018 08:18:16 AM UTC, comment #18: 

Yes the cset is:
"5 weeks ago Daniel J Sebald Use default title bar to preserve GUI float decorations (bug #53276)"

It isn't limited to Windows 7, on my Windows 10 boxes I see the same issue. I agree with Torsten that such basic functionality shouldn't be given up too quickly on just one platform.

I'm not sure if shortcuts are the best option, esp. if valid for just one platform. Better have as much uniform behavior for Octave across all OS-es, so IMO if these shortcuts are introduced they should work on OSX and Linux as well.

I'll try to check today what happens if the patch from comment #13 is applied, thanks.

Philip Nienhuis <philipnienhuis>
Project Member
Sun 10 Jun 2018 08:17:16 AM UTC, comment #17: 

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:


"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.

Dan Sebald <sebald>
Sun 10 Jun 2018 07:52:12 AM UTC, comment #16: 

Just to be sure: Is 05a690606fd5 the big changeset from a month and a half ago?

Torsten Lilge <ttl>
Project Member
Sun 10 Jun 2018 07:50:07 AM UTC, comment #15: 

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.

Torsten Lilge <ttl>
Project Member
Sun 10 Jun 2018 06:48:12 AM UTC, comment #14: 

Here's the patch that will add shortcut keys for the case of a lost title bar in Windows 7.  Let me know if that is decent solution.  The shortcuts are:

CTRL+ALT+U: Undock

I kind of like the shortcut keys.  If you think it is a worthwhile thing, I'll let Torsten handle the choice of shortcuts and whether they should be configurable and stored in the settings file.  This prototype illustrates how to add the shortcuts without the aid of a menu addAction().

(file #44348)

Dan Sebald <sebald>
Sun 10 Jun 2018 01:20:32 AM UTC, comment #13: 

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:


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

(file #44342)

Dan Sebald <sebald>
Sat 09 Jun 2018 09:52:59 PM UTC, comment #12: 

In comment #8:
My guess is that it will be the big changeset from a month and a half ago.

Yes that cset was it.
(A bit more recomping that you think as first one needs to build a dist archive ("make dist"), then crosa-compile it in mxe-octave.)

(I usually do it like "hg -v update -r 25354" and before it "hg -v update -r 25353"- those consecutive numbers are easier than the hashes.)

Philip Nienhuis <philipnienhuis>
Project Member
Fri 08 Jun 2018 08:42:26 PM UTC, comment #11: 

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)

Philip Nienhuis <philipnienhuis>
Project Member
Fri 08 Jun 2018 08:02:42 PM UTC, comment #10: 

From your screenshots it appears the whole QDockWidget title bar is missing (not to be confused with the Window Manager's title bar).  It makes more sense that would be the problem rather than losing just the single tool button.

Note that if we were to switch over to the custom title bar when the octave_dock_widget is floated, we could probably add a double-click to the custom title bar layout.  Since the top-level window can't be dragged back into the QMainwindow in any case, we'd effectively lose no features that way.

Dan Sebald <sebald>
Fri 08 Jun 2018 07:37:50 PM UTC, comment #9: 

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.

Philip Nienhuis <philipnienhuis>
Project Member
Fri 08 Jun 2018 04:33:12 PM UTC, comment #8: 

To be fair, one of the worse bugs is KDE Oxygen, which I don't think is Qt developer's problem.  But yeah, not much responsiveness from those projects.

I think there will be evolution of the look-and-feel and behavior of the V.E. once users get to know it more.  Maybe at next year's OctConf developers can take in all the feedback and work out details.

It sounds as though you may have not used the GUI in Windows 7 for a while and are just noticing the missing title bar.  Also, if you are using Qt 5.7.1, your system is past the two bug reports I cited.

Well, assuming that change from 4.4.0 to 5.0.0 has to pass through the file octave-dock-widget.cc to affect the title bar, here is the file history for the individual file:


My guess is that it will be the big changeset from a month and a half ago.  There are only a couple changesets involving octave-dock-widget.cc in that range, so at least it wouldn't be too much recompiling.  If you have the time and desire, perhaps you could build and test the parents of the two most recent changeset, i.e.,

hg update 05a690606fd5
[./bootstrap... make... test]
hg update 3764ebd3b589
[./bootstrap... make... test]

to figure out exactly which changeset is responsible.

Dan Sebald <sebald>
Fri 08 Jun 2018 09:15:41 AM UTC, comment #7: 

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 Nienhuis <philipnienhuis>
Project Member
Fri 08 Jun 2018 09:08:09 AM UTC, comment #6: 

No I have left that setting alone (= inactive). Changing it has no effect.
Setting or unsetting "show status bar" also has no effect.

BTW I found a workaround for redocking; I also have 4.4.0 installed, and that still has a dock button. As 4.4.0 and 5.0.0 share the qt-settings file I can have undocked panes redocked in 5.0.0 by docking them in 4.4.0, exiting 4.4.0 and starting 5.0.0. Involved, but it helps :-)
(And it shows that the missing dock button is a recent phenomenon, i.e., from after 4.4.0)

in <mxe-octave>/... /qtbase.mk:
$(PKG)_VERSION  := 5.7.1

As to the Qt bug reports: I'm too unfamiliar with Qt programming to fully grasp them, but
looks like what I see.
The other bug report doesn't ring a bell with me, sorry.

As to "dock all":
Could be convenient for last-chance rescue cases, yes; but I think a better alternative would be to have a separate dock/undock command for each individual pane in the main menu's Window drop-down menu. Or maybe a tick box "docked" or so after the pane name in that Window menu.
IIRC Matlab has that too, at least for some panes.

Philip Nienhuis <philipnienhuis>
Project Member
Fri 08 Jun 2018 08:03:00 AM UTC, comment #5: 

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

Torsten Lilge <ttl>
Project Member
Fri 08 Jun 2018 07:25:32 AM UTC, comment #4: 

Philip wrote: "[*] 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?"

Yes, thanks Philip...

I know, one can hardly tell that one of the V.E. panels has been undocked because the size and location of the undocked QDockWidget is almost exactly the same as when it is docked...unless having undocked--moved/resized--docked--undock.  That is, Qt sort of remembers the location of the undocked QDockWidgets, but the first undock is the issue.  I don't know why Qt doesn't do a better job with that.  I didn't know what to do: Place the undocked variable_dock_widget in one of the corners?  Center it the desktop?  Randomly pick a corner?  So I just left it, partly because we had so much other unstable code to deal with.  Nonetheless, early on I recognized the confusion "The panel didn't float?  Oh, it did float; it just ended with the same exact dimensions."

As for the original bug, could it be yet another Qt bug/issue or framework limitation?  Check this one out:


It indicates that dragging to undock leaves the title bar, but not pressing the undock button.  Is this what you are seeing?  I think the above bug report suggests that it is a duplicate to this one


which has been closed and indicates a fix in Qt version 5.0.2.  What Qt version are you using Philip?

I don't know how often we can keep putting in work-arounds for Qt bugs.  What would we do?  Maybe when the widget is floated go back to a custom window somehow?

I'm OK with a "dock all" feature.  Even without it being a specific work-around for this issue, it might be a convenient thing to have.

Dan Sebald <sebald>
Fri 08 Jun 2018 06:37:38 AM UTC, comment #3: 

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:
(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)

Philip Nienhuis <philipnienhuis>
Project Member
Thu 07 Jun 2018 09:21:29 PM UTC, comment #2: 

Philip, not only the dock button is missing as can be seen in the screenshot, it's obviously the complete "inner" title bar when the widget is floating. Are you using the custom style for the widget titles? Does a change of this preference has any influence?

Torsten Lilge <ttl>
Project Member
Thu 07 Jun 2018 08:42:43 PM UTC, comment #1: 

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:


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.

Dan Sebald <sebald>
Thu 07 Jun 2018 09:03:21 AM UTC, original submission:  

Title should say it all :-)

As an example a pic of the variable editor is attached, but the text editor (that I usually have undocked and on a second monitor) doesn't have a dock button either.
This makes it impossible to redock panes - unless there's another way that I'm unaware off?

If the only way to redock panes is moving it into place (doesn't work on Windows) it would be a Good Thing to invent some alternative way, e.g. some context menu item of a main menu View command "Redock all panes". The "Reset Default Window Layout" button is a bit too invasive IMO.

Philip Nienhuis <philipnienhuis>
Project Member


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

Attached Files
file #44437:  octave-var-window.png added by lostbard (15KiB - image/png)
file #44438:  octave-main-window.png added by lostbard (54KiB - image/png)
file #44424:  bug54078_ttl_v01.patch added by ttl (4KiB - text/x-patch)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by lostbard (Posted a comment)
  • -email is unavailable- added by ttl (Posted a comment)
  • -email is unavailable- added by sebald (Posted a comment)
  • -email is unavailable- added by philipnienhuis (Submitted the item)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.




    Follow 23 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-06-26 philipnienhuis Open/ClosedOpen => Closed
    2018-06-26 philipnienhuis StatusReady For Test => Fixed
    2018-06-26 philipnienhuis StatusFixed => Ready For Test
        Open/ClosedClosed => Open
    2018-06-26 ttl StatusNone => Fixed
        Open/ClosedOpen => Closed
    2018-06-25 sebald Attached File- => Added octave-float_octave_dock_widget_for_windows-djs2018jun25.patch, #44439
    2018-06-25 lostbard Attached File- => Added octave-var-window.png, #44437
        Attached File- => Added octave-main-window.png, #44438
    2018-06-25 philipnienhuis Attached File- => Added bug_54078_patch_comment26.PNG, #44436
    2018-06-24 ttl Attached File- => Added bug54078_ttl_v01.patch, #44424
    2018-06-14 sebald Attached File- => Added octave-make_window_deparent-djs2018jun14.patch, #44370
    2018-06-10 sebald Attached File- => Added Window_dropdown_menu_Screenshot_from_2018-06-10_12-40-23.png, #44353
    2018-06-10 philipnienhuis Attached File- => Added Docked_pane_no-pane_border-A.jpg, #44350
        Attached File- => Added Docked_pane_no-pane_border-B.jpg, #44351
        Attached File- => Added Undocked_VE-no_resize_cursor.jpg, #44352
    2018-06-10 philipnienhuis Attached File- => Added Undocked_VE-no_resize_cursor.jpg, #44349
    2018-06-10 sebald Attached File- => Added octave-shortcut_keys_for_gui_widget_dock_undock_close-djs2018jun10.patch, #44348
    2018-06-10 sebald Attached File- => Added octave-windows_7_test_lost_title_bar-djs2018jun09.diff, #44342
    2018-06-08 philipnienhuis SummaryNo more dock button on undocked panes => No more QDockWidget title bar and dock button on undocked panes under Windows
    2018-06-08 philipnienhuis Attached File- => Added bug54078_VE_subpanels_after_undockb-click.PNG, #44327
        Attached File- => Added bug54078_undocked_VE_w_1_undocked_subpanel.PNG, #44328
    2018-06-07 philipnienhuis Attached File- => Added vared_windows_500_no_dock_button.PNG, #44315

    Back to the top

    Powered by Savane 3.5