Dan, thanks for the modification. I have pushed the patch with changeset
http://hg.savannah.gnu.org/hgweb/octave/rev/05a690606fd5

I think, this report can be closed now?

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

https://savannah.gnu.org/bugs/index.php?53276#comment21

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

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:

https://savannah.gnu.org/bugs/?53835

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)

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)

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:

https://savannah.gnu.org/bugs/?53807

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

to

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

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

@Mike: I've downloaded Kubuntu 18.04

https://savannah.gnu.org/bugs/?53276#comment89

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:

https://bugs.kde.org/show_bug.cgi?id=393076

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

https://bugs.kde.org/show_bug.cgi?id=393076

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.

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

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.

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?

https://en.wikipedia.org/wiki/List_of_Intel_Core_i5_microprocessors

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);
      }

to

    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.

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:

https://hg.savannah.gnu.org/hgweb/octave/rev/2b8442c890d8

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:

https://www.phoronix.com/scan.php?page=news_item&px=KDE-Plasma-Regress-Explanation

https://blog.martin-graesslin.com/blog/2017/07/plasma-wayland-and-qt-5-9-and-beyond/

Here are some more errata:

https://community.kde.org/Plasma/5.9_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.

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

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.

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.

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

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

@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

     m_terminalView->setColorTable(cols);

+    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

http://doc.qt.io/archives/qt-4.8/qwidget.html#autoFillBackground-prop

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)

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.

Nice!

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

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.

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.

@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 #53409.  Bug #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.

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

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

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

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

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)

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

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.

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.

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:

  bool
  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*,
                                                               octave_dock_widget*)),
                        this, SLOT (make_window_on_one_focus_change (octave_dock_widget*,
                                                                     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)

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

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

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.

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.

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.

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";
+#else
+        titlebar_tooltip = "";
+#endif

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.

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?

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

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

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.

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)

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

HTH

I'll shortly start building with newest patch

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:

https://savannah.gnu.org/bugs/index.php?53355

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?

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.

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

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?

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.

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.

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

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.

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.

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

https://savannah.gnu.org/bugs/?53275#comment15
https://savannah.gnu.org/support/download.php?file_id=43487

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.

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

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

http://doc.qt.io/qt-5/qwidget.html#setParent-1

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

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


content


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

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.

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.

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)