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


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

Submitter:  Philip Nienhuis <philipnienhuis>
Submitted:  Sat 03 Mar 2018 05:09:18 PM 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:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup

Jump to the original submission

Sun 06 May 2018 09:20:21 PM UTC, comment #113: 

Yes, I believe this can be closed.  You've already covered some loose ends with a number of other bug fixes.

I've tested on both Mint/Cinnamon and KDE/Plasma and everything looks great, minor exceptions.  For some reason the Fusion Widget Style and Behavior system setting produces thin octave_dock_widget titles (see attached screen shot) but acceptable.  All the rest of the system selections produce the expected thickness.  Cascading style sheets is something new to me, so maybe there is a better way of controlling that.  Not worth fixing, or wait a month or two until the more non-style-related issues have stabilized.

Dan Sebald <sebald>
Sun 06 May 2018 02:34:02 PM UTC, comment #112: 

Dan, thanks for the modification. I have pushed the patch with changeset

I think, this report can be closed now?

Torsten Lilge <ttl>
Group Member
Sun 06 May 2018 05:24:32 AM UTC, comment #111: 

Attached is a changeset modification that makes the title bar text color work again.  I also found some ways to put more spacing between title bar icons which is much easier to use with the mouse.

(file #44104)

Dan Sebald <sebald>
Sat 05 May 2018 05:28:26 PM UTC, comment #110: 

Not using the custom title bar is the core issue.  See the first half of this post:


The Qt documentation is indicating that one doesn't get full decorations if the custom title bar is set.  The construct of setParent(0); setTitleBarWidget(customtitle); setParent(0); is not documented as doing anything, and in fact the rules that are defined in the documentation would suggest the above should not have full decorations after the setParent(), if anything.  set_title() uses the custom title bar.

For example, I couldn't have said in the KDE bug report https://bugs.kde.org/show_bug.cgi?id=393076 that for Oxygen setParent(0); setTitleBarWidget(customtitle); setParent(0); is not producing full decorations therefore it should be fixed.  But I can say that for Oxygen setTitleBarWidget(0); setParent(0); is not producing full decorations and therefore it should be fixed.

The title color.  I added

                    "QDockWidget {\n"
                    "  %6\n"

to the cascading style sheet and it appears to fix the issue.  Before a new changeset candidate, though, what do you mean by compactness?  Are you referring to the title bar buttons?  I've mentioned before I feel those are too close and difficult to select.  We can add padding to those buttons in the CSS and spread those apart.

Dan Sebald <sebald>
Sat 05 May 2018 11:47:49 AM UTC, comment #109: 

Dan, what was the reason for not using the custom title bar (setWindowTitle instead of set_title)? The drawback of using the standard title bar is that the background color can be set but a selected foreground color is ignored resulting in non-readable titles when selecting a dark background color. moreover, the custom title widget id slightly compacter.

However, when using set_title again, the variable editor can not be docked anymore, it always stays floating. Other widgets can be re-docked again once they are floating.

And what are the "#if 0" constructs in octave-dock-widget.cc and varable-editor-model.cc for?

Torsten Lilge <ttl>
Group Member
Fri 04 May 2018 05:48:12 PM UTC, comment #108: 

Ah, File Browser not File Editor.  OK, I see that now.  My bad...

Well, I've backed out all the changes to main-widnow.cc (see attached changeset) and I created a new bug report to explain what the issue is:


This appears to clear up the File Browser highlight, although there should be a couple changes there as explained in Bug #53835.

I also address another issue in the latest patch by making the dock/undock step earlier and dropping one of the state variables.

(file #44092)

Dan Sebald <sebald>
Fri 04 May 2018 05:05:05 AM UTC, comment #107: 

I have not mentioned the file editor but the file browser.

As I can see, the special handling of the editor in focus_changed () is still there (which is good as long there is no replacement). However looping over the focus chain is just a fallback if the widget that has focus is not a child of a dock widget.

Torsten Lilge <ttl>
Group Member
Thu 03 May 2018 09:08:10 PM UTC, comment #106: 

You mentioned the file editor.  This probably has to do with the change I made to main-window.cc:

* main-window.cc (main_window::focus_changed): Simplify this routine by
  eliminating the indefinite loop search through all previous focus objects.
  Instead, just look for the currently focused object in all the octave dock
  widgets and if not found don't change the highlight.  Also drop the special
  handling for the editor.

Attached is a patch where I backed out the above change.  Give that a try.

I do feel though that the focus_changed routine is overly complicated with it search through the previous focused object "linked list" that could result in an infinite loop by happenstance so is arbitrarily limited to 100 counts or something.  Anyway, the file editor is treated with special consideration.  I took that out, and that may be why on your system there is a highlight issue on the first try.  My feeling is that there should be a better way of having the File Editor deal with it more locally, such as in some focusInEvent virtual function override.

Yes, the items addressed in this patch have grown.  I never suspected so many related bugs in KDE and Qt to arise.  I myself prefer more atomic changes, but I really don't want to put too much more time in this changeset.  If anything, I'd consider removing the recent bug addressed, i.e., everything contained within

+// See  Octave bug #53807 and https://bugreports.qt.io/browse/QTBUG-44813
+#if (QT_VERSION >= 0x050302) && (QT_VERSION <= QTBUG_44813_FIX_VERSION)

into a separate patch at Bug #53807.  But the way that this has gone is folks flag all these items as lumped into the one feature whether consciously or not, i.e., "this or that is flaky on some platform, so the patch must be wrong".  Where does one separate these?  If you want, read the commit message summary and break things up.  But then we'll have five different bug reports to repeat the process on.

The way I look at it, the patch addresses some major issues and restores full Qt QDockWidget mousing features.  Any issues that remain are small, easy fixes that can be dealt with in new bug reports as they arise.  The one exception is KDE Oxygen--I can't see any sort of work-around for that.  So, given 4.4.0 was just released and its the start of a new cycle, maybe it is better to do the bulk change which gives beta-testers time to find issues.

(file #44078)

Dan Sebald <sebald>
Thu 03 May 2018 08:20:17 PM UTC, comment #105: 

I have tested the patch from comment #104. The file browser's title bar is always highlighted, regardless the widget that really has focus (and therefore also has a highlighted title bar). The behavior gets back to normal once the file browser has got focus.

Obviously, this patch addresses several different issues. Is it possible to separate the patch into several smaller ones?

Torsten Lilge <ttl>
Group Member
Thu 03 May 2018 08:01:46 AM UTC, comment #104: 

Record discussion length?  Probably not even close, hee-hee.  Plus, we've uncovered maybe three other significant bugs, so divide that post-length by three.  And now I've uncovered a fourth significant bug (Qt), mentioned here:


I think we've managed pretty well with so many unsuspected significant bugs in the mix.  One keeps thinking it is programmer-error when in fact it's something outside their control.

I've spent some time going over the code and created a new version (attached) that I believe is ready to go.  It has maybe a half-dozen bug fixes and improvements, e.g., a crash-bug due to deleted variable window and refocusing the variable editor, better restoring of geometry in the fullscreen-to-docked mode, etc.

The most significant is dealing with another bug in KDE/Qt (Qt's responsibility).  It has to due with QDockWidget mouse-drag floated windows being un-focusable.  (The bug manifests in the variable_dock_widget objects.)  I basically had to use the same approach as was used for drag-float of the octave_dock_widgets, but slight variation on the theme.  The solution circumvents the problem by redocking and refloating the drag-float QDockWidget, i.e., turn it from a drag-float window to a direct-float window.  If one pays close attention, the undock-button-click floated windows have a quick display while the drag-floated windows flash  off and on.

The bug exists in all KDE themes.  To see a before and after comparison, go to the file variable-editor.h (after having done the patch command) and change

#define QTBUG_44813_FIX_VERSION 0x999999


#define QTBUG_44813_FIX_VERSION 0x009999

and recompile.  Just create some variable panels:

>> x = eye(3); openvar x; y = magic(5); openvar y; z = x; openvar z;

and drag the title bar to float.

The number 0x999999 is meant to be replaced by whatever version of Qt it is for which the developers provide a fix.  (Well, I sure hope it is a Qt version and not something KDE-related.)

As for the KDE-with-Oxygen theme non-movable windows bug, it seems to have gotten about as much response from KDE developers as what I got from OpenGL/swrast/Gallium developers a few years back.  But unlike those bugs, I'm not going to dig into any KDE window manager code and try building a window manager to test and debug.

So the summary is that with the latest patch everything looks pretty good, but avoid using Oxygen on KDE.  I won't look at this one much more.

(file #44067)

Dan Sebald <sebald>
Fri 13 Apr 2018 07:25:08 AM UTC, comment #103: 

Maybe the defunct Oxygenis also responsible for the lack of maximize buttons on the title bar that I mentioned long ago in some other bug report. IIRC Rik saw the same then.

[OT] do we have the record discussion length here? (now at #103)

Philip Nienhuis <philipnienhuis>
Group Member
Thu 12 Apr 2018 11:40:50 PM UTC, comment #102: 

@Rik: octave_dock_widget assigns names to the object just as seen in the title, e.g., Variable Editor.  Maybe that is one approach: specify the name in the Special Windows settings.  Of course, "Variable Editor" refers to the octave_dock_widget and not what the octave_dock_widget contains.  Plus, KDE puts these ampersand shortcuts in names that might mess things up as far as that strategy.  It's really all the octave_dock_widgets that should be modified.  If I could have just changed the setting for all, say, NET::Dock type of windows and have Oxygen work as designed, that would have been a big step.

Dan Sebald <sebald>
Thu 12 Apr 2018 11:23:19 PM UTC, comment #101: 

@Dan: I'm glad that Kubuntu 18.04 looks good.  I mean to upgrade fairly soon.  Also, I regularly use the Special Windows settings for KDE to do various things.  I wouldn't have any fear.  You can delete the rules easily enough.  However, I did try and find a way to set special rules on the V.E. window but I couldn't find a way to uniquely identify it.  This was before your comments here.  Maybe I could go back and try harder at some point.

Rik <rik5>
Group administrator
Thu 12 Apr 2018 10:28:15 PM UTC, comment #100: 

@Mike: I've downloaded Kubuntu 18.04


and loaded the bundle onto a hard drive.  I will say that Kubuntu 18.04 is by far the most solid version of KDE I've seen.  The fonts all look nice, it has a really sharp appearance, very responsive even when resizing the first bulky page of HTML code in the Octave Documentation window.  The plug-and-play for thumb drives puts up a notice so one can quickly jump its contents.  Changing system settings doesn't make a mess of things, etc.  For those who are using KDE, I suggest skipping ahead to something on the order of Kubuntu (Qt 5.9.x).

So, Kubuntu helped as it gave me enough confidence to investigate things.  I now agree with Rik that this looks like a bug isolated to KDE Oxygen (not Qt, and at least not Octave's responsibility).  And I filed a bug report with KDE here:


I think that is the best place to start.  I was going to just ignore this, but then I saw some survey about the most common themes used in KDE and 75% of users said Oxygen.

I'm attaching a screenshot of Octave GUI to show how nice it looks for Breeze theme.  As for the Oxygen behavior, I have confirmed now that there is a problem (hence the bug report).  Specifically it is the aspect of themes setting shown in the second attachment, the Application Style : Widget Style and Behavior.  There are four options, three of which (Breeze, Fusion and Windows 9x) that work perfectly fine with the freshened changeset that I will attach in a followup post.  The fourth is Oxygen.  Selecting that results in the window decorations not appearing.  Everything else about Oxygen behavior works...the taskbar icon, the float/unfloat, the double-click title, the drag outside the main GUI.  That's a hint leading to my explanation in the bug report


that this is simply a case of "noborder" in the KDE code not being correct.

Also, from the KDE internal code, I could tell that somewhere in the System Settings is a Window Manager rules.  I will attach a third screenshot showing that there is a button in Window Manager : Window Rules : Appearance & Fixes which is sort of a customized way of circumventing and fixing any rules that KDE is using, with specificity.  If one is daring, give it a try.  However, I wasn't that daring given the warning message that appears--without giving details about the window's type and name on runs the risk of modifying behavior for every visible window.

Dan Sebald <sebald>
Mon 09 Apr 2018 02:02:46 AM UTC, comment #99: 

I agree that this feels like a big change that should go on the development branch rather than the about-to-be-released stable branch.

Rik <rik5>
Group administrator
Sun 08 Apr 2018 05:36:04 PM UTC, comment #98: 

@Torsten: Yes, there is a very extensive patch here.  I'm attaching an updated version in which I've outright removed the tooltip "Use <Alt> + <Left Mouse Button> for moving the window".

@Philip: Thanks for the clarification on KDE Oxygen.

I think that KDE Qt and the window decorations stuff is all outside of our control.  Therefore, I propose dropping that tooltip about how to move a window for a broken decorations window.  The current patch as best I know is adhering to documented Qt standards and therefore should work.  Works great on Mint/Cinnamon.  Appears to work for Philip for non-Oxygen Mageai KDE.  Seems to work well for Mint KDE.  So I'd propose applying the patch in the default branch and try to get some testers for MXE/Windows and Mac OSX.

I've tested the Oxygen window theme on Magiea.  The decorations work fine here.  But what gives me pause is I had to select Oxygen theme in two places: one the look-and-feel and another the decorations.  That's right, KDE appears to have settings for decorations as a separate entity.  That makes me wonder a bit about the likelihood of a bug slipping into KDEs decorations code.  Why not just make it all one thing?  In fact, there is even a third category of mouse cursor theme, which can be Oxygen.

To boot, Mageai has several other issues in KDE.  I'm also attaching a screenshot with some annotations pointing out the font is incorrect in some windows, there is this odd extra tab space placed in the line of text I'm typing, and the desktop taskbar is missing icons and text.  The missing text came when I switched to Oxygen theme.

(file #43843,

Dan Sebald <sebald>
Sun 08 Apr 2018 07:40:20 AM UTC, comment #97: 

This would be okay for me.

However, I lost track if there is still one of the patches of this report required and if only Oxygen is affected here.

Torsten Lilge <ttl>
Group Member
Sat 07 Apr 2018 11:30:45 PM UTC, comment #96: 

I think this all might be just a crappy bug within the Oxygen widget set.  If I change to any other Widget style such as Breeze, QtCurve, or Fusion then an undocked window such as Documentation has TitleBar decorations and I can move it and resize it.  And the Variable Editor windows and sub-windows also work and can be re-position within the Variable Editor container, or by themselves.

I'm wondering if we should just leave things the way they are and say that this is a problem with Qt and the Oxygen styling.

Rik <rik5>
Group administrator
Sat 07 Apr 2018 06:19:13 PM UTC, comment #95: 

On my desktop (where it worked fine since comment #74) I had "Breeze' widget style, on my laptop (where this bug still manifested itself) it was set to 'Oxygen'. Setting it to "Breeze" as well made the bug go away.
So it isn't just a Qt but also the particular KDE/Plasma style.

What a nasty bug.

Philip Nienhuis <philipnienhuis>
Group Member
Sat 07 Apr 2018 06:47:08 AM UTC, comment #94: 

From previous discussion and testings regarding  fully decorated windows (bug #52797), the chosen style of the KDE Plasma window manager is important, too. The style "Oxygen" was the one that broke the decoration, all other style were working fine.
Maybe Dan is using another style than Rik and Philip?

Torsten Lilge <ttl>
Group Member
Fri 06 Apr 2018 08:49:52 PM UTC, comment #93: 

@Dan comment #91: now you're pushing it very far :-)
Just relax: even the predecessor of my desktop's Core i5 (i.e., a core Duo) had a 64 bit mode. The Lenovo also has an i5 (a little older and 35% slower), both are x86_64 and both have access to 8 GB RAM. Hope you are reassured now.

I fully agree with your analysis that we're hunting down Qt- rather than Octave bugs. As I stated several tens of posts ago, I can live with them until Mageia chooses to update Qt, plus I work mostly on Windoze anyway.

Thanks again for your tireless attempts to get this solved, appreciated.

Philip Nienhuis <philipnienhuis>
Group Member
Fri 06 Apr 2018 06:22:25 PM UTC, comment #92: 
Mike Miller <mtmiller>
Group Member
Fri 06 Apr 2018 06:17:18 PM UTC, comment #91: 

@Philip: "Gigabyte mobo and i5 CPU".  i5?  Does that mean you are choosing the i586 build of the software?  On both the Lenovo and no-name computer?  I typically choose the x86_64 version so that all the memory beyond 4GB is accessible.  We should be clear what build we are referring to.  I wouldn't consider x86_64 and i586 to be the same builds.  Qt could be quite different internally for i586 and x86_64.

@Rik: What build are you choosing on Mint KDE/Plasma?

Dan Sebald <sebald>
Fri 06 Apr 2018 05:16:45 PM UTC, comment #90: 

With regards to KDE/Qt, I wonder if anything would happen if we changed

    if (m_start_gui)
        m_workspace_model = new workspace_model ();
        m_status_bar = new QStatusBar ();
        m_command_window = new terminal_dock_widget (this);
        m_history_window = new history_dock_widget (this);
        m_file_browser_window = new files_dock_widget (this);
        m_doc_browser_window = new documentation_dock_widget (this);
        m_editor_window = create_default_editor (this);
        m_variable_editor_window = new variable_editor (this);
        m_workspace_window = new workspace_view (this);


    if (m_start_gui)
        m_workspace_model = new workspace_model (0);
        m_status_bar = new QStatusBar (0);
        m_command_window = new terminal_dock_widget (0);
        m_history_window = new history_dock_widget (0);
        m_file_browser_window = new files_dock_widget (0);
        m_doc_browser_window = new documentation_dock_widget (0);
        m_editor_window = create_default_editor (0);
        m_variable_editor_window = new variable_editor (0);
        m_workspace_window = new workspace_view (0);

and then as a first step call "make_widget()" on these.  Perhaps KDE/Qt would behave better if the windows were initially top-level full decoration rather than docked widgets.

Dan Sebald <sebald>
Fri 06 Apr 2018 05:15:43 PM UTC, comment #89: 

If this kind of thing is important to you, and if you have a spare machine or time to install a VM, you can try the Kubuntu 18.04 beta installer, which has KDE Plasma 5.12 and Qt 5.9.4.


Mike Miller <mtmiller>
Group Member
Fri 06 Apr 2018 05:07:18 PM UTC, comment #88: 

Computer hardware hasn't anything to do with it, humor...

KDE Qt just isn't robust.  Another non-warm-fuzzy is general KDE bugs.  On Mint KDE/Plasma I had to disable the screen saver otherwise Plasma would freeze.  And now this morning on Mageia KDE/Plasma I select the Application Menu (what's known as Start in Windows) and the icons are all missing next to the application names.

I'm reaching the conclusion that we are dealing with buggy Qt and/or KDE and there is little we can do beyond what I've already done with this changeset:


to hopefully address the non-movable windows.  This "missing decorations" bug is probably something different.  It could be somewhere else in Octave GUI code there is something putting Qt in a strange state, but the fact things work here so well would suggest not.  To dig into this deeply means analyzing exactly what window-manager build is being used and being able to identify only one or two things different between a working system and a failing system.

Here's that blog I saw about someone who ran into KDE/Qt 5.8.x problems:



Here are some more errata:


One may think, but there is no bug of the sort we are seeing with missing window decorations.  That's probably because few applications out there have tried the approach Octave is using, i.e., converting back and forth to a top-level window.  Others may approach things differently.

We can try what Torsten suggests and avoid using inheritance, something that is standard C++, and see if for some odd reason that improves the situation for Rik and Philip.  However, I think the best approach is what Rik suggests:  wait for KDE/Plasma with Qt 5.9 which hopefully arrives soon and fixes these issues.

Dan Sebald <sebald>
Fri 06 Apr 2018 11:57:41 AM UTC, comment #87: 

That pic looks the same as on my desktop with an el cheapo Gigabyte mobo and i5 CPU (see comment #74). It's on more pricey HW (Lenovo X230 with an expensive screen (not graphics) option) that it still fails.
To make it more obscure, on my desktop the "default" repo copy that I keep current with "hg pull && hg update" is > 9 month old (so it survived a system upgrade from Mageia-5 to Mageia-6), on my laptop I re-cloned it last Easter.
Now you again .....

BTW the "─║atest patch" - exactly which one is it? as comment #74 was based only on what was in core octave at that time.

Maybe again mention what I wrote in the bottom half of comment #67?

Philip Nienhuis <philipnienhuis>
Group Member
Fri 06 Apr 2018 08:57:58 AM UTC, comment #86: 

@Philip: I've installed Mageia 6 with KDE/Plasma (x86_64 build) on a hard drive.  It took a lot of time installing all the packages needed for Octave, but I finally managed a build.  And as you might guess, according to Murphy's Law, the latest patch here applied to a fairly recent version of the repository works perfectly!  See the attached screenshot for the full decorated windows.  Float button works, title-bar double-click works, drag-and-drop outside the main GUI window works.

So, I've now installed as near as I can tell the same Linux distro that Rik's using and the same distro that Philip is using and things work nicely here.  I've got a brand name HP.  What kind of cheap hardware are you using?

Seriously, I kind of suspected this would happen.  There is probably some general non-robustness about Qt on KDE/Plasma...say a compiler difference or GTK difference on our systems or something arcane that is causing a difference.  Maybe I'm choosing a different compiler or utilities at install out of habit.  Don't know.  I've seen somewhere a programmer complained about Qt 5.8.x cause a bad problem on KDE/Plasma for their company.  I don't know what to say.  The only thing that comes to mind if either of you want to install 5.9, I think SuSE might have a distro version that has it.

Dan Sebald <sebald>
Thu 05 Apr 2018 08:21:57 PM UTC, comment #85: 

Comment #84: We could try that.  The current patch moves slightly away from the original motivation of the octave_dock_widget : label_dock_widget inheritance in the sense that octave_dock_widget no longer uses the custom title bar in the patch; it's only the variable editor subpanels that use the custom widget.  That is, after the patch, octave_dock_widget no longer needs the "label" part of things.  But we should confirm just exactly what the change is before and after.  The only thing that could have had an affect in


is the fact that

setFeatures (QDockWidget::DockWidgetMovable); // not floatable or closeable

is done one class removed.

@Philip: By "movable" in the past context and now, do you mean movable in the sense of dragging by the title bar?  Or by using the Alt+left_mouse_button technique?  Also, in Comment #10 you provided a snapshot of what your system looks like.  Could you replicate the same view with the setup you used in Comment #74?  In other words, are you back to the same point with the current tip as back in Comment #10?

Dan Sebald <sebald>
Thu 05 Apr 2018 07:41:50 PM UTC, comment #84: 

Related to my comment #37:
Since cset http://hg.savannah.gnu.org/hgweb/octave/rev/ed9ba20d6ed3 seems to have introduced the non-movable floating widgets on Philip's system (comment #10), I am wondering whether the octave_dock_widget could be restored into its original state without relying on the new intermediate class label_dock_widget. By this, the new functionality of the VE dock widgets is introduced wihtout touching the octave_dock_widgets.

Torsten Lilge <ttl>
Group Member
Thu 05 Apr 2018 07:34:26 PM UTC, comment #83: 

Well, the question is whether Philip is experiencing odd problems related to that Qt bug, just the way Rik might be.  It's possible that different systems (two monitors, laptop, desktop-one-monitor) affect the window position coordinates, but it is all conjecture.  That is, will this clear up with 5.7.1 and greater?  If we check things in, we sort of lose a reference point.

@Philip: From what I'm gathering, the patches of Comment #69


and Comment #76


behave about the same and this seems to currently work on your non-laptop setup.  Could you provide a summary of the behavior of floated windows prior to the patch on your laptop (that's KDE/Plasma 5.6.1/2 as well, correct)?

Dan Sebald <sebald>
Thu 05 Apr 2018 03:31:12 PM UTC, comment #82: 

So that indicates that the patch does some good, but isn't perfect.  Should we apply it or not?  I have no vote since it doesn't work for me, but that is my system's special failure.

Rik <rik5>
Group administrator
Thu 05 Apr 2018 02:24:47 PM UTC, comment #81: 

After applying the patch from comment #69 and then backing it out (hg rollback) the situation is worse: no more resizing of undocked panes anywhere except for the editor pane that has a status bar.

Philip Nienhuis <philipnienhuis>
Group Member
Thu 05 Apr 2018 09:30:02 AM UTC, comment #80: 

in 2nd paragraph: should be  "Moving around and resizing undocked subpanels..."

Philip Nienhuis <philipnienhuis>
Group Member
Thu 05 Apr 2018 09:28:34 AM UTC, comment #79: 

After testing the same on my laptop I see that the bug is still there :-(
Applying the patch from comment #69 doesn't make any visual difference AFAICS.

Moving undocked panels around can be done with Alt-LMB. Moving around undocked subpanels (= undocked variable editor tabs) works fine as ever, except for the top border (when moving the resize cursor up along a side border it disappears as soon as it comes next to the title bar).

However, resizing doesn't work for "normal" undocked panels except for the Editor pane as that has a status bar where there's apparently a resizing "anchor".
On the sides of the undocked panes the cursor changes shape but not into a resize cursor, it looks more like the cursor you see between adjacent docked panels when moving/resizing them within the main GUI window.

So all in all an enigmatic bug.

Philip Nienhuis <philipnienhuis>
Group Member
Wed 04 Apr 2018 10:57:46 PM UTC, comment #78: 

@Dan: In response to the new patch in comment #76, the background is correctly colored with that patch.

Rik <rik5>
Group administrator
Wed 04 Apr 2018 09:56:57 PM UTC, comment #77: 

@Rik: If you have a little bit of time, perhaps you could experiment with the toplevel windows trying to get the full decorations on your version of KDE.  The code where this takes place is very short.  It's this hunk from octave_dock_widget.cc:

  // make the widget floating
  octave_dock_widget::make_window (bool)
    // prevent follow-up calls by clearing state variable
    m_waiting_for_mouse_button_release = false;

    // the widget has to be reparented (parent = 0), preferably
    // from a non-toplevel widget otherwise may not have full
    // decorations, e.g., no taskbar icon and always in front
    setFloating (false);
// Remove after thorough testing 3/20/18    m_parent->removeDockWidget (this);
    setParent (0, Qt::Window | Qt::CustomizeWindowHint | Qt::WindowTitleHint |
               Qt::WindowMinMaxButtonsHint | Qt::WindowCloseButtonHint);

It's surprisingly tricky code.  That routine should be executed whenever there is a float-button-press, double-click-on-title-bar or drag-panel-outside-GUI-window.  Use a debugger, or put some comments in like

std::cerr << "parent: " << parent() << "\n";

before (should be non-zero parent) and after the setParent(0) to make sure that the window's parent is in fact 0 after, etc.  You might try putting that step back in that explicitly removes the widget from the QMainWindow.  The issue I was coming across originally is that without doing that setFloating(false) first the conversion was from a floated QDockWidget to a floated toplevel window and all that happened was a parent change, no decorations change...just like you are currently seeing.

Dan Sebald <sebald>
Wed 04 Apr 2018 09:45:24 PM UTC, comment #76: 

@Torsten, @Rik: Attached is a new changeset version that should fix the terminal color background.  It's actually a simple fix once I realized what was happening, but it isn't a general fix which I'm not sure is possible.  I added a portion of the cascading style sheet in

diff --git a/libgui/qterminal/libqterminal/unix/QUnixTerminalImpl.cpp b/libgui/qterminal/libqterminal/unix/QUnixTerminalImpl.cpp
--- a/libgui/qterminal/libqterminal/unix/QUnixTerminalImpl.cpp
+++ b/libgui/qterminal/libqterminal/unix/QUnixTerminalImpl.cpp
@@ -188,6 +188,11 @@ void QUnixTerminalImpl::setBackgroundCol


+    QString css = QString ("TerminalView {\n"
+                           "  background: %1;\n"
+                           "}\n").arg (color.name ());
+    setStyleSheet (css);
 void QUnixTerminalImpl::setForegroundColor (const QColor& color)

Perhaps that negates the widget's QPalette::Window role, I don't know or if it even matters.  There is a FIXME comment just above the function I altered, so Torsten may want to review that hunk.

I suppose this is what "cascading" is about, but the reason one can't do something general at the octave_dock_widget level (which is what autoFillBackground


is doing) is that one sort of needs to know the object class type.  If I just grab the background color from QDockWidget's perspective:

QPalette widgypal = widget()->palette();
QColor widgycol = widgypal.color(QPalette::Window);

I don't know if that QDockWidget is holding a TerminalView object, so one would be setting the TerminalView background in a CSS description that is the wrong color.  In some sense, the cascading style sheet is like virtual functions (the compiler/Qt resolves them) except that in the CSS case all levels are applied as opposed to over-riding.  We could attempt a generalized approach by somehow grabbing the widget() class type and injecting that class name in the octave_dock_widget level.  However, I think that is a rather sophisticated algorithm along the lines of Qt's autoFillBackground algorithm.

(file #43805)

Dan Sebald <sebald>
Wed 04 Apr 2018 06:20:31 PM UTC, comment #75: 

Thanks Philip.  That is good news.  If you'd like to try the patch in Comment #69, feel free, but there should be only minor change in some corner cases which go easily unnoticed.

I'm working on the background color issue that Rik pointed out, but I'm not sure if those changes should be part of this patch or if it should be a separate bug.  In any case, there's likely to be another rev.

@Rik: Regarding color, I've narrowed things down, but I'm running into an issue of the terminal view's background role color being set back to the ivory color

[Do a Preferences... change]
tR: 0 tG: 0 tB: 0
name: TerminalDockWidget R: 0 G: 0 B: 0
name: TerminalDockWidget R: 214 G: 214 B: 214

The first printout is the QUnixTerminalImpl::setBackgroundColor table-color as a result of the Preferences change.  The second is the QDockWidget's widget() background color prior to CSS setting.  The third is after CSS setting and looks to be GUI default.  So maybe there is some CSS setting that controls this; I'll keep looking.

Dan Sebald <sebald>
Wed 04 Apr 2018 05:55:37 PM UTC, comment #74: 

After brief testing some good news:

A clean tip (25120:3f0aca5c36b4 Update Dutch translation ...), without the patch from comment #69, doesn't show this bug anymore.
Everything works: resizing all around the undocked panes, panning panes around, docking /undocking, etc.


Do you still want me to try the patch from comment #69?

Philip Nienhuis <philipnienhuis>
Group Member
Wed 04 Apr 2018 06:32:44 AM UTC, comment #73: 

Just putting a reference explaining how the background of the QTerminal window is automagically filled in:


because nowhere in QUnixTerminalImpl.cpp is the background actually set.  Just

void QUnixTerminalImpl::setBackgroundColor (const QColor& color)

The patch uses style sheets so, "Warning: Use this property with caution in conjunction with Qt Style Sheets. When a widget has a style sheet with a valid background or a border-image, this property is automatically disabled."

Will have to figure out how to set the background in some other way because unfortunately QDockWidget doesn't have such a CSS property.

Dan Sebald <sebald>
Tue 03 Apr 2018 11:39:50 PM UTC, comment #72: 

Attached is the floating Command Window on top of the rest of the GUI.  When I hit the dock button it correctly goes back into the rest of the GUI.

Rik <rik5>
Group administrator
Tue 03 Apr 2018 11:28:20 PM UTC, comment #71: 

Still nothing?  Oy.  Could you include a screen shot of the floated Workspace window after pressing the float icon in the title bar?  The press the unfloat icon again.  Does it become a toplevel window then?

The white outline of the Command Window: I think I see what the issue is.  That outline is the very end of the displayed text.  There must be a background setting in the CSS which I will look for.  It is supposed to be black, right?  I.e., black Command Window on a slate gray main window.

Dan Sebald <sebald>
Tue 03 Apr 2018 11:11:32 PM UTC, comment #70: 

I will have to leave testing up to Philip.  I can apply the patch, and build with it, but for me the undocked windows never have an active title bar that I can use to move or resize them.  This is with KDE and Qt 5.6.1.

Also, if this patch is applied then we will need to figure out how the CSS is working because it causes a pale ivory outline around the command window.  There is a screenshot that shows this which is attached to comment #58.

Rik <rik5>
Group administrator
Tue 03 Apr 2018 09:03:55 PM UTC, comment #69: 

I'm attaching a new patch with a slight modification to the "toplevel window via drag-and-drop" algorithm.  The reason for this was the not-quite-correct behavior when using main_window::focus_changed().  See here


So rather than pin the toplevel-change on focus behavior, I looked for an event that correlates with drop outside the main window versus drop inside the main window.  I whittled all the observed event codes down to QEvent::ActivationChange.

So the basic change is an additional conditional in the event handler:

  octave_dock_widget::event (QEvent *event)
    // low-level check of whether docked-widget became a window via
    // double-click or via drag-and-drop
    if ((event->type () == QEvent::MouseButtonDblClick && ! isFloating ())
        || (event->type () == QEvent::ActivationChange && m_waiting_for_mouse_button_release))
        bool retval = QDockWidget::event (event);
        if (isFloating () && parent () != 0)
            m_waiting_for_mouse_button_release = false;
            emit queue_make_window ();
        return retval;

    return QDockWidget::event (event);

i.e., (event->type () == QEvent::ActivationChange && m_waiting_for_mouse_button_release) where m_waiting_for_mouse_button_release takes the place of the active_dock_changed() signal connection.

This works very nicely for me in both Cinnamon, Qt 5.5.1-4ubuntu3 and KDE-Plasma, Qt 5.6.1-2build1~~xenial (the problematic one).

@Philip: The current tip of either stable or default, e.g.,


should have the bug fixes meant to address the Qt bug.  You should first build and test that on Mageia 6 Plasma/KDE, Qt 5.6.2.  That will be your reference point, as I don't think there is much more we can do for the Qt range of 5.6.1 to 5.7.1-.  Rik doesn't have movable windows in his version of Mint KDE/Plasma with Qt 5.6.1; I do.  I think it may have something to do with the way the desktop coordinates are set, e.g., multiscreen system, that sort of thing.  If you are unable to move widgets and/or windows with that base reference, then I think we'll have to find someone with Qt 5.7.1 or greater and write other problems off to the Qt bug if the latest versions work.

I do sometimes see strange behavior similar to what you described with the Variable Editor panels--if I have the floated variable panel too big, sometimes it won't re-dock in the position I try, but then I just drop it somewhere within the Variable Editor, grab the window again and then it repositions fine.

(file #43790)

Dan Sebald <sebald>
Mon 02 Apr 2018 08:14:09 PM UTC, comment #68: 

@Philip: We still have that Qt 5.6.1 bug to deal with, so it's not worth testing this on KDE just yet.  Recall that Qt 5.6.1 bug is associated with Bug #53276 and Bug #53409Bug #53276 changeset is now in the stable branch, but not the Bug #52409 changeset, which means windows can't be moved within the main window.

I have done some testing on KDE/Plasma with Qt 5.6.1, applying all the patches.  The changset here then results in a KDE version which works nicely except for the drag-and-drop outside of the main GUI window which I will look at tonight or tomorrow.

Dan Sebald <sebald>
Mon 02 Apr 2018 07:27:51 PM UTC, comment #67: 

Got home early from vacation, so I just tested.

In short: doesn't help much.


- The Editor pane (was undocked before I started Octave) cannot be moved by the title bar. It just has a spot in the lower right corner, in the status bar, where the pane can be dragged bigger and smaller, that's it.

- The Variable Editor (VarEd) was docked. I can drag it out of Octave's main window, and i stays there. And it can be dragged by its title bar, and all around it has spots where the cursor changes in a resize cursor.
It is an unstable situation. After a while, or after some fiddling, suddenly the undocked VarEd pane changes position & size and morphs in a similar behavior as the Editor pane - no more movable by its title bar, no more resizing (not even in the lower right corner).

This behavior applies to any pane. Docking and undocking the Editor pane, or any other pane, works similarly, but after a while the medicine's half-life seems to have passed :-)

In summary, it seems to help for a while just after a pane was undocked.
It seems completely unpredictable when the change from moveable to unmoveable occurs. It looks (flagrant guesswork!) like it has to do with focus and re-focussing.

- Given the discussion in this bug report and in bug #53409;
- Given the fact that this seems due to a Qt-5.6.1 to 5.7.0 bug;
- Given that -from what I read- few distros use Qt 5.6.1 to 5.7.0;
- Given that I have Q t5.6.2 on my development Linux box but mainly use Octave on Windows where mxe-octave has a much later Qt;
- just to repeat what I wrote in an earlier bug report discussion:

==> is it really worthwile to you to invest loads of time fixing a workaround for this upstream bug?
Mind you, I am very grateful to you that you try, I regularly use Octave on Linux as well but for me this bug is not a showstopper - and after all, I suppose Mageia will update Qt anyway sometime.
It's up to you. If you still want to go on, I'm prepared to let my Linux boxes serve as guinea pigs for your patches etc. As long as I get clear instructions :-)

Philip Nienhuis <philipnienhuis>
Group Member
Sun 01 Apr 2018 10:16:12 PM UTC, comment #66: 

I'll try asap, could be Wednesday night before I can.

Philip Nienhuis <philipnienhuis>
Group Member
Sun 01 Apr 2018 09:28:16 PM UTC, comment #65: 

Philip, can you confirm that the patch sequence in comment #62 does fix the issue covered by this report and thus can be applied on stable?

Torsten Lilge <ttl>
Group Member
Sun 01 Apr 2018 09:22:32 PM UTC, comment #64: 

Sorry, comment #63 was meant for another bug report.

Torsten Lilge <ttl>
Group Member
Sun 01 Apr 2018 09:21:40 PM UTC, comment #63: 

Dan, thanks for having a look into the routine.

The max. count should be a last measure for preventing an endless loop while searching for the main dock widget that contains the element currently having the focus. In most of the cases, the first condition is already met.

If there are possibilities to make the routine more robust, I would be happy to push a related changeset.

Torsten Lilge <ttl>
Group Member
Sat 31 Mar 2018 08:38:44 PM UTC, comment #62: 

I'm freshening the changeset for this bug by taking out the segment that was used in Bug #53392.  With the latest patch, one must first apply


then the attached changeset.

As I updated this, I noticed that every once in a while the drag-and-drop route to a toplevel window does work.  It seems to be a rare combination or sequence of the focus for various docked panels have the focus.  It could be that this is a bug going back to active_dock_changed() signal.  So, the attached patch isn't quite 100% yet, but the bug-fix in the above link should still stand on its own.

(file #43750)

Dan Sebald <sebald>
Fri 23 Mar 2018 09:34:37 PM UTC, comment #61: 

The most recent patch here


stands on its own without any other applied patches.  But if
Bug #53392 is applied first, then this patch needs an update.  My thinking is to get those other two issues first, otherwise those testing this change on KDE will be confused by the other problems.

Dan Sebald <sebald>
Fri 23 Mar 2018 09:19:31 PM UTC, comment #60: 

This bug, #53392 and #53409 all seem related in some way.  What patches should be applied and in what order?

John W. Eaton <jwe>
Group administrator
Fri 23 Mar 2018 12:08:27 AM UTC, comment #59: 

Changes the Command Window border?  Strange.  I've posted a link in


about a Qt bug for Qt 5.6.1.  We may have to find some other version to test on KDE.

Out of curiosity, if it isn't too much trouble, could you double-click on the title bar window of "Workspace" or "Command Window" and see if that floats/docks in a sane way?  I could install Qt 5.6.1 here to try and fix things, but in lieu of that bug report I don't see the point.  Also, I'm not sure I want to venture into downloading and building the latest Qt 5.7.1 or whatever it is.

Dan Sebald <sebald>
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.

Rik <rik5>
Group 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>
Group 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>
Group 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:

    // the widget has to be reparented (parent = 0), preferably
    // from a non-toplevel widget otherwise may not have full
    // decorations, e.g., no taskbar icon and always in front
    setFloating (false);
// Remove after thorough testing 3/20/18    m_parent->removeDockWidget (this);
    setParent (0, Qt::Window | Qt::CustomizeWindowHint | Qt::WindowTitleHint |
               Qt::WindowMinMaxButtonsHint | Qt::WindowCloseButtonHint);

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:

    // Since floating widget has no parent, we have to read it
    QSettings *settings = resource_manager::get_settings ();

    settings->setValue ("MainWindow/windowState", m_parent->saveState ());
    // Stay window, otherwise will bounce back to window by default because
    // there is no layout information for this widget in the saved settings.
    setParent (m_parent, Qt::Window);
    m_parent->addDockWidget (m_recent_dock_area, this);
    // recover old window states, hide and re-show new added widget
    m_parent->restoreState (settings->value ("MainWindow/windowState").toByteArray ());
    setFloating (false);
    focus ();
    QApplication::setActiveWindow (this);
    show ();

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:

  octave_dock_widget::event (QEvent *event)
    // low-level check of whether docked-widget became a window via double-click
    if (event->type () == QEvent::MouseButtonDblClick && ! isFloating ())
        bool retval = QDockWidget::event (event);
        if (isFloating () && parent () != 0)
            disconnect (m_parent, SIGNAL (active_dock_changed (octave_dock_widget*,
                        this, SLOT (make_window_on_one_focus_change (octave_dock_widget*,
            emit queue_make_window ();
        return retval;

    return QDockWidget::event (event);

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 Lilge <ttl>
Group 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>
Group 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 Lilge <ttl>
Group 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>
Group 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 Lilge <ttl>
Group 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>
Group 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 Lilge <ttl>
Group 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>
Group 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>
Group 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

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

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

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:

+#if defined (Q_OS_UNIX)
+        // needed anymore?
+        titlebar_tooltip = "Use <Alt> + <Left Mouse Button> for moving the window";
+        titlebar_tooltip = "";

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

Philip Nienhuis <philipnienhuis>
Group 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>
Group 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 Lilge <ttl>
Group 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 Lilge <ttl>
Group 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

     setParent (0, Qt::Window | Qt::CustomizeWindowHint | Qt::WindowTitleHint |
                Qt::WindowMinMaxButtonsHint | Qt::WindowCloseButtonHint);

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

hg revert --all
patch -p1 < octave-float_as_toplevel-djs2018mar17.patch
[rebuild, however one has rebuild set up]

(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

-    setParent (0, Qt::Window | Qt::CustomizeWindowHint | Qt::WindowTitleHint |
-               Qt::WindowMinMaxButtonsHint | Qt::WindowCloseButtonHint);


+    setParent (0, Qt::Window);

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 (pre-patch the header is shorter and the float/close buttons at top-right are scrunched nearer to one another, whereas in the header is taller and the buttons are more spread out.&nbsp; 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

Philip Nienhuis <philipnienhuis>
Group 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>
Group 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():

  octave_dock_widget::toplevel_change (bool toplevel)
    QObject *dockobj;
    const char *docksig;

    if (titleBarWidget ())
        dockobj = m_dock_action;
        docksig = SIGNAL (triggered (bool));
        dockobj = m_default_float_button;
        docksig = SIGNAL (clicked (bool));

    if (toplevel)
        // This is a fallback in case the attempt to create a floated
        // top-level window fails and the QDockWidget remains a child
        // of the QMainWindow.
        connect (dockobj, docksig, this, SLOT (default_dock (bool)));

        // Could be dragging window, so must wait until there is a
        // change in focus.
        if (parent () != 0)
          connect (qApp, SIGNAL (focusChanged (QWidget *, QWidget *)),
                   this, SLOT (make_window_on_one_focus_change (QWidget *, QWidget *)));
        connect (dockobj, docksig, this, SLOT (make_window (bool)));

        // Making into a widget immediately will mangle the double-click
        // status and cause problems on followup button clicks.
        if (parent () == 0)
          emit queue_make_widget ();

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

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 Lilge <ttl>
Group 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 Lilge <ttl>
Group 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:

# Parent  ca43264971ea35e5aa2ea9816abcd8bd97eae308

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

for i=1:4
  eval(['var' num2str(i) ' = eye(5); openvar var' num2str(i)]);

?  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 Lilge <ttl>
Group 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:

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

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

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

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

Some general comments that could possibly use feedback:

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

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

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

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

    // the widget has to be reparented (parent = 0), preferably
    // from a non-toplevel widget otherwise may not have full
    // decorations, e.g., no taskbar icon and always in front
    setFloating (false);
    m_parent->removeDockWidget (this);
    setParent (0, Qt::Window);

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

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

to get that window to the front.

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

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

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

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

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


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

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

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

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


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>
Group 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 Lilge <ttl>
Group 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 Lilge <ttl>
Group 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>
Group 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:

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

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:

    QWidget *newwidget = new QWidget (this);
    setStyleSheet (QString ("QDockWidget {border-style: none;}"));
    QVBoxLayout *vbox = new QVBoxLayout (newwidget);
    vbox->addWidget (m_title_widget);
    vbox->addWidget (widget ());
    vbox->setSpacing (0);
    vbox->setContentsMargins(1, 1, 1, 1);
    setWidget (newwidget);
    setParent (0, Qt::Window);
    m_title_widget->show ();

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

octave's added label line



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&

Philip Nienhuis <philipnienhuis>
Group 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 Lilge <ttl>
Group 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 Lilge <ttl>
Group 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 Lilge <ttl>
Group 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:

conventional window line
octave's added label line



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>
Group 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>
Group 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>
Group Member


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

Attach Files:

Attached Files
file #43791:  Floating_Cmd_Window.png added by rik5 (125KiB - image/png)
file #43581:  DocX2.png added by philipnienhuis (379KiB - image/png)
file #43574:  Windows.PNG added by philipnienhuis (147KiB - image/png)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by rik5 (Updated the item)
  • -email is unavailable- added by siko1056
  • -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)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.


    Follow 25 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-05-07 ttl StatusPatch Submitted Fixed
        Open/ClosedOpen Closed
    2018-05-06 sebald Attached File- Added kde_fusion_title_narrowness_Screenshot_20180506_160306.png, #44108
    2018-05-06 sebald Attached File- Added octave-float_as_toplevel-djs2018may05.patch, #44104
    2018-05-04 sebald Attached File- Added octave-float_as_toplevel-djs2018may04.patch, #44092
    2018-05-03 sebald Attached File- Added octave-float_as_toplevel-djs2018may03.patch, #44078
    2018-05-03 sebald Attached File- Added octave-float_as_toplevel-djs2018may02.patch, #44067
    2018-04-12 sebald Attached File- Added kubuntu_18_53276patch_looks_great_Screenshot_20180412_014406.png, #43904
        Attached File- Added kde_setting_that_affects_decorations_Screenshot_20180412_024147.png, #43905
        Attached File- Added kde_window_manager_rules_border_setting_Screenshot_20180412_154510.png, #43906
    2018-04-09 rik5 StatusReady For Test Patch Submitted
    2018-04-08 sebald Attached File- Added octave-float_as_toplevel-djs2018apr08.patch, #43843
        Attached File- Added mageia_oxygen_Screenshot_20180408_103430_annotated.png, #43844
    2018-04-06 sebald Attached File- Added nice_qt5-6-2_on_kdeplasm_mageia_Screenshot_20180406_033000.png, #43820
    2018-04-04 sebald Attached File- Added octave-float_as_toplevel-djs2018apr04.patch, #43805
    2018-04-03 rik5 Attached File- Added Floating_Cmd_Window.png, #43791
    2018-04-03 rik5 StatusNone Ready For Test
    2018-04-03 sebald Attached File- Added octave-float_as_toplevel-djs2018apr03.patch, #43790
    2018-03-31 sebald Attached File- Added octave-float_as_toplevel-djs2018mar31.patch, #43750
    2018-03-22 rik5 Attached File- Added Outlining_around_Command_Window.png, #43636
    2018-03-21 siko1056 Carbon-Copy- Added siko1056
    2018-03-19 sebald Attached File- Added octave-float_as_toplevel-djs2018mar19.patch, #43597
    2018-03-16 philipnienhuis Attached File- Added DocX2.png, #43581
    2018-03-16 sebald Attached File- Added octave-float_as_toplevel-djs2018mar17.patch, #43579
    2018-03-16 philipnienhuis Attached File- Added Windows.PNG, #43574

    Back to the top

    Powered by Savane 3.13-4b48.
    Corresponding source code