bugGNU Octave - Bugs: bug #53276, GUI: undocked panes cannot be...


bug #53276: GUI: undocked panes cannot be moved, or resized along upper border

Submitted by:  Philip Nienhuis <philipnienhuis>
Submitted on:  Sat 03 Mar 2018 05:09:18 PM UTC  
Category: GUISeverity: 3 - Normal
Priority: 5 - NormalItem Group: Regression
Status: NoneAssigned to: None
Originator Name: philipnienhuisOpen/Closed: Open
Release: devOperating System: GNU/Linux

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 Jump to the original submission)

Thu 22 Mar 2018 09:46:37 PM UTC, comment #58:

The patch from comment #54 doesn't work for me. This is with KDE/Plasma, Qt 5.6.1, and undocking a widget such as "Workspace" or "Command Window". In addition, it changes the color around the Command Window. A screenshot is attached.

(file #43636)

Rik <rik5>
Project Administrator
Tue 20 Mar 2018 08:10:11 PM UTC, comment #57:

When trying with a fresh clone I found that the crash isn't confined to just Doc pane on Terminal pane.
I'll file a separate bug report (bug #53392).

So that may explain what I described in comment #40 - and it is probably not related to Dan's stuff at all.

Philip Nienhuis <philipnienhuis>
Project Member
Tue 20 Mar 2018 07:11:56 PM UTC, comment #56:

Oh now I catch what Torsten meant in comments #49 - #53.
I see now that my comment #48 was a bit out of order. Sorry for that.

But... I also see that I can get the crash on the default branch too (w/o any of Dan's patches) on my Mageia 6 Plasma/KDE box.

Steps to reproduce (fairly reliable):
1. Open a GUI
2. Inside the GUI, drag the Documentation pane into a separate position (not tabbed with any other pane) to the right of the Terminal pane (in any other position you won't see the bug)
3. Move the Documentation pane back to the left onto the Terminal pane to get it into tabbed position

=> result: the pane remains blue for a long time, Octave is unresponsive, Octave's main menu Minimize button doesn't work (Octave minimizes momentarily but flashes back to previous size), after a while Octave disappears from sight = crash.

Philip Nienhuis <philipnienhuis>
Project Member
Mon 19 Mar 2018 11:20:06 PM UTC, comment #55:

Torsten, a couple items.

1) We really should fix this bug


before doing a thorough test. It would be nice to test how float/redock works when there are no other visible features.

2) Do you know what is happening with KDE and the ampersand that is showing up in toplevel window title bars? E.g., "&Command Window" and "Edi&tor"? Is it automatically placing a shortcut key representation in there because of some associated action?


Dan Sebald <sebald>
Mon 19 Mar 2018 11:14:01 PM UTC, comment #54:

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:

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:

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:

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)

Dan Sebald <sebald>
Mon 19 Mar 2018 08:51:25 PM UTC, comment #53:

Well, then the crash occurs on the default branch and not on a trial patch.

Torsten <ttl>
Project Member
Mon 19 Mar 2018 07:43:33 PM UTC, comment #52:

Torsten, I am on the default branch now (= 5.4.0+) currently w/o Dan's patches.

Philip Nienhuis <philipnienhuis>
Project Member
Mon 19 Mar 2018 06:47:02 PM UTC, comment #51:

@Philip: Then I misunderstood your sentence "Essentially this means I accepted the state of the development branch for now". I thought you were back on the default branch without any patches.

Torsten <ttl>
Project Member
Mon 19 Mar 2018 06:06:03 PM UTC, comment #50:

That would be a bug report on a trial patch by Dan.

pic = of comment #41. But agreed, tht is not very informative.
Somewhere I have another one from just before the crash, I'll dig it up.

Philip Nienhuis <philipnienhuis>
Project Member
Mon 19 Mar 2018 06:13:57 AM UTC, comment #49:

Philip, to which pic/comment are you referring? Maybe there should be a separate bug report on this signal 11 crash?

Torsten <ttl>
Project Member
Sun 18 Mar 2018 10:03:20 PM UTC, comment #48:

I backed out Dan's csets so that at least on Windows I have a "dock" button on the undocked panes. (That'll get me through work this week :-) )
Essentially this means I accepted the state of the development branch for now.

Then I found that moving the docked but separate Documents pane onto the Terminal pane (to get them tabbed) gives many issues (hang and then a signal 11 crash; see pic in a few comments back), but moving the Terminal pane onto the Documents pane works fine. So my conclusion is that there are various inconsistencies between panes.

Dan I really appreciate your efforts but do you think it'll be worthwhile? I do hope so, but I have some fear that you're spending time on fixing or working around upstream problems.

Philip Nienhuis <philipnienhuis>
Project Member
Sun 18 Mar 2018 09:21:28 PM UTC, comment #47:

Reply to comment #42

Dan, there always were problems on certain window managers with the decoration of the floating widgets (see bug #52797). However, as far as I understand the issue Philip is seeing is new on his window manager.

Moreover, has the change proposed in comment #14 (dropping double unparenting) solved the issue? I really have difficulties to keep track of the changes.

What I wanted to suggest is to finalize the VE widgets as pure Qt dock widgets without touching the main octave_dock_widgets. Then, this feature is fixed and should run on every window manager. Afterwards, we can focus on the issues with the main dock widgets.

Torsten <ttl>
Project Member
Sun 18 Mar 2018 10:23:33 AM UTC, comment #46:

I see no differences, nor different behavior, between the patches of comment #31 and comment #36, on Linux KDE/Plasma.

For some reason the Documents pane works very messy.
Undocking and redocking sometimes gives a remnant undocked pane. Moving it outside the tabbed CLI/Doc pane and later moving it back into tabbed position leads to a hang and then crash (signal 11).
(Maybe related to geometry settings somewhere?)
AFAICS the other panes work better.

What I do see on Windows is that with both patches the dock button in the undocked "main" panels is gone, so there's no more way to re-dock them into the main window.
(Subpanels from the VE still do have such a button so they can be redocked in the VE.)

Well, what to do?
I'm unsure because you have spent so much time on an issue which AFAIU is mainly due to a specific window manager.
Again, before those patches it all worked but it was just not obvious how; except for resizing undocked panes along the upper border that still doesn't work.

Philip Nienhuis <philipnienhuis>
Project Member
Fri 16 Mar 2018 09:38:17 PM UTC, comment #45:

Also, the double-click and drag-outside-main-window are sort of the questionable new element at the moment. Pressing the the float/unfloat button should be the more direct route, so if that works better that would be nice to know. The ghost frame thing is probably Workspace and File Browser placed within the same window. I recall you saying something about KDE will lump all similar sub-windows into one stacked taskbar icon. It could be that is what we are dealing with now, i.e., how to reparent/set-flags in such a way that is done as desired.

Dan Sebald <sebald>
Fri 16 Mar 2018 09:34:15 PM UTC, comment #44:

It could well be that various concealed bugs are popping up now. You uncovered several that related to threading isn't it.
My linux laptop is available for testing, my pleasure (although it is now cross-building until tomorrow morning).

About patching, it is very easy to "hg rollback" to backout the latest cset w/o much of a trace.
To backout a plain diff patch, just "hg update -C" also works fine.
Indeed, just a matter of personal preference.

Enjoy the weekend.

Philip Nienhuis <philipnienhuis>
Project Member
Fri 16 Mar 2018 09:22:34 PM UTC, comment #43:

Comment #40: "After a while and some clicking around the Documentation pane reappeared, and I could drag it (it had a blue title bar) but there was also a ghost Documentation pane tabbed & docked with the Terminal pane. Weird."

Comment #41: "screenshot of situation with semi-undocked Documentation pane
(file #43581)"

OK! Getting somewhere, excellent! I like seeing that full-decorated frame around the Documenation widget.

The peculiar behavior you describe is just the sort of thing I was dealing with and which I now have functioning properly on my system (Cinnamon) with the patches attached in recent past posts. I solved some of the strange frame/no-frame/float/no-float issues by the issuing make_window() and make_widget() in queued fashion here and there. So, now it looks like we need to tweak things to make it work consistently on other Qt systems, like KDE/Plasma.

It's a Friday, and I prefer ending Friday's on an up note. So lets take a break and revisit. Thanks.

Regarding the patches, in development I generally don't apply the patch via the official "hg patch" route but instead make them a temporary change. That is, if someone gives me a patch to try, I just make sure I have a recent tip (or some particular relevant point in the repository) then apply the patch as though it is simply a difference:

patch -p1 < first_attempt.patch
["hg diff" here will show what the differences are]
[build the application with the above changes, didn't work]
hg revert --all
[removes all the changes]
patch -p1 < second_attempt.patch
[build again, should take just a couple minutes, didn't work]
hg revert --all
patch -p1 < maybe_third_attempt_works.patch
[build again, yeah this time it works]
hg revert --all

It's all a matter of preference. Generally, I try avoiding multiple patches and just redo the original.

Dan Sebald <sebald>
Fri 16 Mar 2018 09:01:35 PM UTC, comment #42:

That's why I'm concentrating on the main dock widgets. In the introduction of the VE dock widgets I tried to affect the octave_dock_widget as little as possible. Why exactly that should have changed things I don't know, but I suspect it is because

falls outside of Qt documentation. Doing a setParent(parent,...) where the parent doesn't change is supposed to do nothing. So, exactly what the above is doing on various systems is hard to tell without having a system to test. This comes back to the question of why the <Alt> sequence comment was added:

Apparently there are systems for which even prior to any of the recent changes the Window-Manager frame is not appearing so can't be used to move the window. So I'm just trying to get those frames back so that we can possibly drop the titlebar tooltip with <Alt> etc. I understand the VE change has caused the issue, but I think it just uncovered the issue.

Dan Sebald <sebald>
Fri 16 Mar 2018 08:57:49 PM UTC, comment #41:

screenshot of situation with semi-undocked Documentation pane

(file #43581)

Philip Nienhuis <philipnienhuis>
Project Member
Fri 16 Mar 2018 08:56:25 PM UTC, comment #40:

With the new patch from comment #31:
For undocked panels the issues I have are still the same.
Some new observations:

  • If there's no file in the undocked editor (gray screen), there's no way at all to resize the panel. Once File|New is clicked, the cursor in the lover right corner of the file status bar changes into a diagonal resize cursor.
  • I didn't know about double-clicking the title bar to dock / undock. Nice!
  • I'll attach a screenshot nevertheless of the situation after I double-clicked the (tabbed) Documentation pane. At first it disappeaed and the menu entries in the main menu didn't work. The (docked) File Browser and Command history still reacted, but the (docked) Workspace was unresponsive. After a while and some clicking around the Documentation pane reappeared, and I could drag it (it had a blue title bar) but there was also a ghost Documentation pane tabbed & docked with the Terminal pane. Weird.

During the time Octave's panels were unresponsive, other programs (browser) didn't respond either.

BTW Torsten's observation (comment #39) about comment #10 is accurate.

What do I need to do to apply patch in comment #36 ? First rollback yours from comment #31?

Philip Nienhuis <philipnienhuis>
Project Member
Fri 16 Mar 2018 08:38:26 PM UTC, comment #39:

But as far as I understand comment #10, the VE dock widgets introduced the problems for Philip moving main dock widgets.

Torsten <ttl>
Project Member
Fri 16 Mar 2018 08:31:22 PM UTC, comment #38:

The patches posted here are the opposite: they modify the main dock widgets without touching the VE variable widgets. The VE widgets are currently standard Qt behavior without adjustments. On a separate bug report


was the addition of a QFrame to highlight the border of VE variable widgets, but that's not an underlying Qt adjustment, simply adding a QWidget on top of the view to prevent the floated VE variable from blending in with the background of the rest of the GUI.

Dan Sebald <sebald>
Fri 16 Mar 2018 08:14:12 PM UTC, comment #37:

I have the impression that we have to separate the dock widgets of the main window and those of the variable editor more precisely in this discussion.

Whereas floating main dock widgets shall give the look and feel of independent applications windows, the variable dock widgets really are dock widgets (no standard window decoration, always on top of variable editor widget, not appearing in task bar).

A possible approach might be to introduce the VE dock widgets without touching the main dock widgets. Any possible improvements of the latter (or of both) can then be done afterwards.

Torsten <ttl>
Project Member
Fri 16 Mar 2018 07:11:48 PM UTC, comment #36:

I'm attaching an updated patch for which the only difference with the previous one is putting back

back in place rather than using Qt::Window. Maybe that will bring back the frame for KDE/Plasma.

(file #43579)

Dan Sebald <sebald>
Fri 16 Mar 2018 06:07:31 PM UTC, comment #35:

Thanks Philip. (That helps, but not necessarily makes clear in my mind how to fix things, ha-ha.) I can see in the snapshots for KDE linux that there is no full decoration for the octave_dock_widgets, both Variable Editor and Editor don't have that outside frame. But, the peculiar thing is that there are Taskbar entries at the bottom of the screen for both of these. If these were child-windows of the QMainWindow GUI, they would not have taskbar icons. So, perhaps there is a setting that is different or wrong. There is the Qt::FramelessWindowHint. In the patch, I changed


which possibly is something I shouldn't have done. Maybe KDE has a default of frameless windows where other flavors of linux WIndow-Managers don't.

I can also notice a subtle difference in the header. In file #43575 (pre-patch) the header is shorter and the float/close buttons at top-right are scrunched nearer to one another, whereas in file #43576 the header is taller and the buttons are more spread out. That is an indication that in fact these are pre- and post-patch, i.e., the first is the custom titlebar and the second is the default titlebar. KDE likes more space with the buttons, I guess. But one thing we could do in the label_dock_widget constructor is use the default buttons to determine the spacing and then also apply that spacing to our custom layout. That way, button spacing will look like something the OS framework does.

OK, I'll think about this. Is there any other feedback? No more snapshots, but generally how the windows function? For example, how about double-clicking on the title bar to float/unfloat windows? Or mouse-drag the panels outside of the QMainWindow GUI to cause them to float? Could you try some of those things, but don't use the Variable Editor. Any window but Variable Editor is fine. Workspace window, Editor window, etc. The problem with Variable Editor is that it is very fresh development and we don't want to conflate ancillary issues due to things like event filters, etc. E.g.,


Those should be different bug reports.

Dan Sebald <sebald>
Fri 16 Mar 2018 05:02:23 PM UTC, comment #34:

Here are some pics form
(1) Windows: all panes resizeble (cursor on any border) and draggable by cursor on any "title"(?) bar
(2) Linux, before patch from comment #21: all panes resizable on any border except upper (but sometimes work, perhaps needs extremely accurate mouse cursor positioning), windows not draggable by upper bar
(3) Linux after patch: panes no more resizable except by cursor on on LR corner


I'll shortly start building with newest patch

(file #43574, file #43575, file #43576)

Philip Nienhuis <philipnienhuis>
Project Member
Fri 16 Mar 2018 08:06:08 AM UTC, comment #33:

To be clear, I think it is the behavior of KDE/Plasma and interference with Qt that makes things confusing.
I think you are doing a great job in trying to fix or work around that, but I hope a next upgrade of Plasma/KDE will not set us back again.

Later today I'll upload screen shots of before & after the patch; they're on my laptop. (Mageia 6 on my desktop box (on which box I'm typing now, booted in Windows) got broken after a (official) kernel update that screwed video; during reboot I read s/th like "falling back to Nouveau driver" and since then no more Linux, so that'll ask for some attention as well this weekend :-( )

What you write about "it will get to be a confusing mess", well, on Window it doesn't look that bad; I'll also upload a screenshot from there.

(btw I know about the command line change, I was at OctConf-2018 where that was discussed and changed)


Philip Nienhuis <philipnienhuis>
Project Member
Fri 16 Mar 2018 07:02:31 AM UTC, comment #32:

Oh yeah, the changeset attached in the previous post is against tip, Philip. So you won't need to update to previous versions. But note that there has been a very recent change in the meaning of "run-octave", i.e., "octave" without any options. Must run "octave --gui" now to get the GUI, and if one accidentally continues using "run-octave &" there is a confounding bug in which an active copy of Octave sits in the background:


Dan Sebald <sebald>
Fri 16 Mar 2018 06:54:40 AM UTC, comment #31:

I'm attaching a patch that does two things compared to the previous patch.

One, it restores highlighting for octave_dock_widget in what should be exactly the same prior to the patch. It uses style sheets for the QDockWidget:


in particular QDockWidget::title using the same background definition used for the custom title (see function set_style()).

Two, I've found a better way of doing the non-float-button methods of creating a top-level window with full decorations, i.e., the drag out of QMainWIndow and double-click on the title bar. It no longer involves changeEvent() and the event filter. Instead it uses a temporary connection to watch for focus change and after that change the signal/slot disconnects. That way there isn't the extra bits of code continually watching the event stream. The best summary of the logic is to look at the slot for toplevelChanged():

It wouldn't surprise if the above construct doesn't even require connections to the default float and close buttons to function properly. But for now, "if it isn't broke, don't fix it" holds true. I find it much easier to understand when there is a stable point to deviate from.

I see a number of small issues here and there, but they are the variety I'd prefer to address with other bug reports because most of them are something prior to this changeset.

(file #43567)

Dan Sebald <sebald>
Thu 15 Mar 2018 10:31:26 PM UTC, comment #30:

This bug is concentrating on the behavior of "octave_dock_widget", which is any of the main features that fit within the main GUI window. These main features are the ones for which the frame and title bar look like any Window-Manager window. A Window-Manager window refers to the operating systems Window-Manager and is outside of Qt's control.

The behavior of the new Variable Editor subpanels can be addressed elsewhere, but that is a different variety. The Variable-Editor dock widgets are not derived from octave_dock_widget and they intentionally do not have a Window-Manager window. In my opinion, if all the variable editor subpanels also have Window-Manager windows and taskbar entries, it will get to be a confusing mess. And if we go that route--that every variable in the Variable Editor window should be floated as a top-level Window-Manager window--then it would make sense that each of those have its own menu bar rather than the single menu bar in Variable Editor. Anyway, that's getting ahead of things and would require a rethink.

Back to the patch, afterward are you seeing a Window-Manager window and can you now drag that window with a mouse click? Could you do a screen capture, or alt-print-screen capture, of floated Workspace window and post here?

Dan Sebald <sebald>
Thu 15 Mar 2018 09:58:29 PM UTC, comment #29:

Before the patch from comment #21

  • undocked panes could not be dragged around by dragging their title bar
  • the undocked panes could be dragged by Alt-LMB anywhere on the pane, and
  • when the cursor was above the right, bottom and left borders and LL and LR corners it turned into a resize cursor enabling the windows to be resized.
  • when hovering the cursor above the top border, it could be resized as well

After the patch

  • undocked panes can still be moved around with Alt-LMB
  • resizing can ONLY be done when the cursor is in the lower right corner. The cursor doesn't change anymore on L, B, R borders and LL corner.

I think the whole thing became deceiving as before the patch that led to this bug report there were "regular" title bars on undocked panes that allowed easy dragging, afterwards they disappeared or changed functionality while there was no indication how to then move the panes nor how to resize them easily.
The confusing thing, at least for me, is that the main windows still has a title bar that allows dragging, and (this is especially confusing and inconsistent) docked panes can be dragged inside the main GUI window by their -well, what is it? title bar?- but once undocked that doesn't work anymore.

In summary, I can say that everything works once you know how, but to me it was pretty unclear.
I'd rather have the way dragging and resizing worked before the multi-pane variable editor was introduced.

BTW the patch from comment #21 didn't apply well (octave-dock-widget.cc hunk 5 and variable-editor.cc hunk 1) but going back rev. a26f8c97df21 ("hg -v update -r a26f8c97df21") solved that.

Philip Nienhuis <philipnienhuis>
Project Member
Thu 15 Mar 2018 07:37:32 PM UTC, comment #28:

I'm just about to create an upgraded changeset. If you describe the highlighting issue, maybe I can fix it. I'm not seeing a difference in highlighting between the tip and the changeset, oh wait... OK, there's a Preferences setting I don't have activated. I should be able to put this back in with CSS.

The titlebar highlighting is a good idea, but I don't find it a pleasant style/pattern. I don't like the gradient pattern for the focused subpanel. (See the attached screenshot.) To me, that gradient gives it the appearance of a system window which happens to be sitting on top of the Octave GUI. And the default of white for the non-active window makes that title bar look like the active one, or more like a data entry widget.

I would think that the nicest option would be to have non-active titlebar be transparent and the active titlebar be the default highlight color. (Sort of like when Rik pointed out the peculiar highlight color for Variable Editor when I had chosen a particular color sky-blue, out of the blue, ha-ha.) Maybe that could be made the default if integrating such options into Preferences is too difficult. What are your thoughts?

I'll add the custom titlebar colors back in just as they currently are, and then maybe we could open another bug/patch entry for alternatives.

(file #43562)

Dan Sebald <sebald>
Thu 15 Mar 2018 05:10:58 PM UTC, comment #27:

@Dan: I was talking about the custom styling and highlighting of the main dock widgets. Without highlighting the active widget it is not always easy to see at first glance, which one has the keyboard focus.

Torsten <ttl>
Project Member
Thu 15 Mar 2018 05:08:04 PM UTC, comment #26:

My comment #22: Concerning testing under KDE, I meant Philip, who has posted this bug, not Rik.

Torsten <ttl>
Project Member
Thu 15 Mar 2018 09:09:20 AM UTC, comment #25:

Yes, the patch can be applied to the latest tip:

patch -p1 < octave-float_as_toplevel-djs2018mar14.patch

Hopefully there are only line offset fuzz-factor differences. I try to stay near the tip when freshening changesets, and I don't see to much activity around octave_dock_widget.cc in the past few days. If there is a conflict, look inside the patch file for a description of the parent:

and update to that version before applying the patch:

hg checkout ca432649
patch -p1 < octave-float_as_toplevel-djs2018mar14.patch

I have an improved way of doing the drag-undock and double-click dock/undock I thought while cycling. I will post that Thursday.

Dan Sebald <sebald>
Thu 15 Mar 2018 06:56:19 AM UTC, comment #24:

On Window there never as a problem, it ll Just Worked fine (even very fine), it was only on my Mageia 6 syste with Plasma desktop that this bug happened.

Tonight (Thu) I'll try the new patch. Can I apply it just on top of -say- today's tip? or should I backout to some revision?

Philip Nienhuis <philipnienhuis>
Project Member
Wed 14 Mar 2018 09:37:37 PM UTC, comment #23:

Needs plenty of testing, I know. I wonder about Windows too. If things work fairly well, then maybe the tooltip about <Alt-F4> movement can go.

The highlighting: You are still seeing the highlighted variable names in the Variable Editor, e.g.,

? That shouldn't have changed. Was highlighting needed for other panels? The whole title bar? CSS might do the trick, but it would be worth confirming that the custom title bar produces unexpected decorations first. Works here, but that doesn't mean custom titlebars would work on all systems (and probably not).

Dan Sebald <sebald>
Wed 14 Mar 2018 09:22:46 PM UTC, comment #22:

Dan, thanks for the patch. It works well on Ubuntu Unity. Especially, I like the way you found for handling the dragging of a docked widget into a floating one. There are still some minor issues but these can be tackled afterwards. Among these, re-enabling a possibility for highlighting the title bar of the active widget would be nice (the custom title bar togehter with custom colors was used for this so far).

Most importantly, I would like to wait for Rik's and my testing on a KDE system, whether floating widgets are movable and maybe fully decorated. Compiling on my virtual KDE box will still take a while.

Torsten <ttl>
Project Member
Wed 14 Mar 2018 08:44:58 PM UTC, comment #21:

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:

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:

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

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


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:

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


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)

Dan Sebald <sebald>
Sat 10 Mar 2018 08:53:04 PM UTC, comment #20:

No need to test either of those patches Philip. I have a fix I implemented last night but will need some free time to create a changeset that you can try later, or maybe Torsten will have applied at some point. The fix actually simplifies things, going back to the non-custom title-bar but requires placing the setParent(0) and setParent(m_parent) in just the right and non-obvious location in the sequence of system events. I just need a bit of time here, thanks.

Dan Sebald <sebald>
Sat 10 Mar 2018 08:30:09 PM UTC, comment #19:

Again, what patches do you want me to test against what release? (see comment #15)

With the latest tip (00ecff875f8a Add nnz ...) I still have the problem that undocked panes can't be moved (Editor, V.E., etc.). (in Linux with KDE/Plasma desktop).
Intriguingly, when I drag tabs out of the V.E., the resulting undocked subpanes CAN be moved around freely.

Philip Nienhuis <philipnienhuis>
Project Member
Fri 09 Mar 2018 08:13:50 PM UTC, comment #18:

When not using unparenting, I expect the floating dock widgets to stay on top of the main window.

Torsten <ttl>
Project Member
Fri 09 Mar 2018 07:34:52 PM UTC, comment #17:

OK, thanks folks. Please wait until the weekend to test Philip. I understand the issue now, which is the loss of the Window-Manager decorations when unparenting and custom title bar. Cinnamon has its idiosyncrasies as well, as it depends on the sequence of doing those two operations when I try a few things.

Torsten, that is what I'm seeing too. The innermost title bar you noted is Octave's custom title bar, but technically is just a widget inside a QVBoxLayout. The second inner bar is the QDockWidget title bar...which actually doesn't act like a title bar anymore because one can't drag the window from it.

I think I can devise a simple setup that doesn't use unparenting, but instead overlays a normal QWidget Qt::Window on top of the QDockWidget and moves the custom title bar from one to the other based upon whether it is docked or undocked. We'll see how that goes.

Dan Sebald <sebald>
Fri 09 Mar 2018 07:15:30 PM UTC, comment #16:

Dan, with the changes proposed in comment #14, I get three title bars for floating (main window) dock widget: One of the window manager and two inner bars.

Torsten <ttl>
Project Member
Fri 09 Mar 2018 01:03:23 PM UTC, comment #15:

@Dan comment #11:
FTR, the bug is about the inability to move undocked panels, not the main GUI window.
Yeah I've found out that KDE/Plasma has its idiosyncrasies these days.

Can you give a precise flow of patches to backout and apply, relative to the dev branch? i.e.,

- backout cset ed9ba20d6ed3 (?)
- apply ....
- apply ....
test & report back

It may be that I'll do this during OctConf, but who knows maybe I have an oppotunity for testing this weekend.

Philip Nienhuis <philipnienhuis>
Project Member
Fri 09 Mar 2018 04:18:04 AM UTC, comment #14:

Actually, the simplest and most reliable solution would be to skip this part of the octave_dock_widget:

Instead, in the previous patch I illustrated that we can effectively mimic the undocked QDockWidget without an actual "title bar", but instead using the following:

I basically transfered the QDockWidget's widget back into itself. But we know we can reliably build a generic window with the system Window-Manager title bar, so why not transfer the QDockWidget's widget into a new window and not worry about that title bar stuff? After the transfer we could simply hide the QDockWidget and then when the new window intends to redock, transfer the widget back to the QDockWidget and show it once again.

Dan Sebald <sebald>
Fri 09 Mar 2018 03:58:07 AM UTC, comment #13:

Attached is another patch for you to try. It's an incomplete proof-of-concept which does the following:

QDockWidget: "It is not possible to remove a title bar from a dock widget. However, a similar effect can be achieved by setting a default constructed QWidget as the title bar widget."

I.e., I set the titleBarWidget to QWidget() and then put the custom title bar in a QVBoxLayout. I'm just curious if this works for KDE.

(file #43496)

Dan Sebald <sebald>
Thu 08 Mar 2018 10:37:41 PM UTC, comment #12:

I forgot to add that I'd really like to address this after applying the patch here:


because in that patch I changed the parent of the title bar objects to the title bar widget (which then is a child of the variable_dock_widget) whereas now the parent for the title bar objects and the title bar itself are all the variable_dock_widget.

Dan Sebald <sebald>
Thu 08 Mar 2018 10:31:47 PM UTC, comment #11:

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

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


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:


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)

Dan Sebald <sebald>
Thu 08 Mar 2018 09:35:44 PM UTC, comment #10:

@comment #2:
FWIW, after backing out that cset undocked pane could be moved again.

@comment #5:
No, Alt doesn't help.
I attach a screen shot of the desktop with Octave and terminal from which I launched .run-octave&

(file #43492)

Philip Nienhuis <philipnienhuis>
Project Member
Mon 05 Mar 2018 06:38:25 AM UTC, comment #9:

Oh, that would be nice if all it took were setting some flags, adding the dock button to the header and a couple signals connecting it all. I will look at this later this week, as I'd like to add in the

button for float/magnify the subpanels to address


Also, I don't know what your preference is, but I'm going to experiment with

to see whether a frame can be added to the floated variable panels and how that looks.

Dan Sebald <sebald>
Mon 05 Mar 2018 06:10:06 AM UTC, comment #8:

The window decoration is controlled by window flags given in setParent ()


Torsten <ttl>
Project Member
Sun 04 Mar 2018 09:08:37 PM UTC, comment #7:

OK, I get your point. Perhaps there is some way to force that decoration regardless of what the OS GUI chooses to do with one of the settings in the QStyle class:


I'll search for background on the issue.

Dan Sebald <sebald>
Sun 04 Mar 2018 11:34:13 AM UTC, comment #6:

@Dan, comment #4: The problem is that the full decoration with conventional title bar does not happen with all window managers. For example, KDE Oxygen style does not decorate the floating widgets. In these cases is it not possible to hide the qt title bar of the widget.

If the two redundant title bars should really be avoided, we would have to drop the conventional decoration of floatings widgets.

Torsten <ttl>
Project Member
Sun 04 Mar 2018 11:24:20 AM UTC, comment #5:

@Philip: Do you have fully decorated floating dock widgets under KDE, i.e. with a conventional window title bar in addition to the widget title bar? Is it possible to move the widget by pressing <Alt> while dragging with left mouse button?

Torsten <ttl>
Project Member
Sat 03 Mar 2018 09:25:08 PM UTC, comment #4:

There does seem to be something strange there, but slightly different on Cinnamon. At first blush, the cursor icon and behavior are as expected. But if I select the top edge of the undocked frame so that the "resize" icon appears and drag down the window size down then let go and slightly move the cursor down to the Octave-added label line (and not move the mouse anywhere outside of that label line), click and the window frame will drag resize again without a change in the cursor icon similar to what you are describing.

Could you describe again exactly what the behavior is with dragging to reposition the window? There is something like this:

Is there some type of difference between clicking/dragging in the conventional window line and the added label line?

Actually, I would like to get rid of that added label line when the dockable widget goes into undocked mode. We can do that now pretty easily at one of the base-class levels; it would mean moving the dock/undock/close buttons up to the main window. To me, that line is redundant when undocked (both lines say something like "Variable Editor") and just takes up a little space that could be used for the content.

Dan Sebald <sebald>
Sat 03 Mar 2018 09:09:04 PM UTC, comment #3:

I just saw that I can resize the upper border, it's just that the cursor doesn't change to a resizing cursor as it does with the lower and side borders.

Philip Nienhuis <philipnienhuis>
Project Member
Sat 03 Mar 2018 08:45:34 PM UTC, comment #2:

bisect yes, but not before Wednesday evening.

IIRC I think after that cset (that I tried for you before it was committed) moving undocked panes around still worked fine.
From my reminiscence I could move tabs out of the undocked V.E. and position them + the V.E. pane freely on the desktop, as I could with other panes (I also have the editor floating somewhere outside the GUI).
But I'll check.

Philip Nienhuis <philipnienhuis>
Project Member
Sat 03 Mar 2018 08:32:02 PM UTC, comment #1:

If you are familiar with hg commands to checkout particular versions, it is likely this changeset:


where the change you noticed came in, either introducing something or uncovering something. Could you do a simple bisection around that time?

Dan Sebald <sebald>
Sat 03 Mar 2018 05:09:18 PM UTC, original submission:

When undocking any pane from the GUI, I cannot move the pane by dragging its title bar. Resizing by dragging the upper border doesn't work either (resizing by dragging the bottom border does work).
The only way to "move" it sideways is by consecutive resizing the right and left border.

This is a recent "regression" (should I call it that way? it used to work properly until a week or so ago).

On Windows it all works fine so it may be a KDE- (Plasma-) specific thing. Yet my KDE setup is fairly "plain vanilla" (mostly OOTB settings).

Mageia 6 Linux, Plasma desktop (KDE)

Philip Nienhuis <philipnienhuis>
Project Member


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

Attach File(s):


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -unavailable- added by rik5 (Updated the item)
  • -unavailable- added by siko1056
  • -unavailable- added by ttl (Posted a comment)
  • -unavailable- added by sebald (Posted a comment)
  • -unavailable- added by philipnienhuis (Submitted the item)

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

    Only project members can vote.


    Please enter the title of George Orwell's famous dystopian book (it's a date):



    Follow 14 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Thu 22 Mar 2018 09:46:37 PM UTCrik5Attached File-=>Added Outlining_around_Command_Window.png, #43636
    Wed 21 Mar 2018 12:14:25 PM UTCsiko1056Carbon-Copy-=>Added siko1056
    Mon 19 Mar 2018 11:14:01 PM UTCsebaldAttached File-=>Added octave-float_as_toplevel-djs2018mar19.patch, #43597
    Fri 16 Mar 2018 08:57:49 PM UTCphilipnienhuisAttached File-=>Added DocX2.png, #43581
    Fri 16 Mar 2018 07:11:48 PM UTCsebaldAttached File-=>Added octave-float_as_toplevel-djs2018mar17.patch, #43579
    Fri 16 Mar 2018 05:02:23 PM UTCphilipnienhuisAttached File-=>Added Windows.PNG, #43574
      Attached File-=>Added Lnx_before_patch.png, #43575
      Attached File-=>Added Lnx_after_patch.png, #43576
    Fri 16 Mar 2018 06:54:40 AM UTCsebaldAttached File-=>Added octave-float_as_toplevel-djs2018mar16.patch, #43567
    Thu 15 Mar 2018 07:37:32 PM UTCsebaldAttached File-=>Added Screenshot_from_2018-03-15_14-35-52.png, #43562
    Wed 14 Mar 2018 08:44:58 PM UTCsebaldAttached File-=>Added octave-float_as_toplevel-djs2018mar14.patch, #43547
    Fri 09 Mar 2018 03:58:07 AM UTCsebaldAttached File-=>Added default_qwidget_titlebar_djs2018mar08.diff, #43496
    Thu 08 Mar 2018 10:31:47 PM UTCsebaldAttached File-=>Added check_if_no_custom_titlebar_works_in_kde_djs2018mar08.diff, #43494
    Thu 08 Mar 2018 09:35:44 PM UTCphilipnienhuisAttached File-=>Added octave_complete_screen.png, #43492

    Back to the top

    Powered by Savane 3.1-cleanup1