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

 
 

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

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

Add a New Comment(Rich Markup)
   

You are not logged in

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

 

( Jump to the original submission)

Thu 14 Jun 2018 09:52:31 PM UTC, comment #25:

... file attached.

(file #44370)

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

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

So, I'll keep thinking about this one.

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

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

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

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

I like the

suggestion.

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

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

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

The shortcut key sequences:

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

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

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

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

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

?????

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

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

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

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

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

(file #44353)

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

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

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

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

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

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

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

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

  • Undocked panes no longer have a title bar. That title bar could be used to drag the pane around on the desktop, so dragging is no more possible.
  • Double-clicking the title bar now works for docking / undocking. For undocked panes there's no more way to maximize the pane to full desktop / minize to taskbar button/ restore pane size.
  • Undocked panes have a toolbar with a working "dock" button.
  • The undocked Variable Editor pane can be right-clicked to get a command "Variable editor toolbar" that works to enable/disable the toolbar.
  • Undocked panes have no clear border indicating where the "grip are" is for resizing panes. Before the patch the cursor changed shape into a proper resize cursor. With the patch it doesn't change. Attached is a photo of the screen (can't take screen shot as then the cursor is hidden) where the cursor is in the lower right position to resize the screen.

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

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

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

(file #44349, file #44350, file #44351, file #44352)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Reply to comment #13

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

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

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

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

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

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

CTRL+ALT+C: Close
CTRL+ALT+D: Dock
CTRL+ALT+U: Undock

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

(file #44348)

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

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

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

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

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

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

(file #44342)

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

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

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

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

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

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

(Title adapted)

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

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

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

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

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

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

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

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

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

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

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

http://hg.savannah.gnu.org/hgweb/octave/log/5523d88bb5d3/libgui/src/documentation-dock-widget.cc

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

to figure out exactly which changeset is responsible.

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

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

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

Philip Nienhuis <philipnienhuis>
Project Member
Fri 08 Jun 2018 09:08:09 AM UTC, comment #6:

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

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

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

As to the Qt bug reports: I'm too unfamiliar with Qt programming to fully grasp them, but
https://bugreports.qt.io/browse/QTBUG-30692
looks like what I see.
The other bug report doesn't ring a bell with me, sorry.

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

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

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

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

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

Yes, thanks Philip...

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

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

https://bugreports.qt.io/browse/QTBUG-30692

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

https://bugreports.qt.io/browse/QTBUG-28872

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

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

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

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

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

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

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

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

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

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

(file #44327, file #44328)

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

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

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

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

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

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

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

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

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

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

Title should say it all :-)

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

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

Philip Nienhuis <philipnienhuis>
Project Member

 

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

Attach Files:
   
   
Comment:
   

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

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

    Only project members can vote.

     

     

     

    Follow 12 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-06-14 sebald Attached File- => Added octave-make_window_deparent-djs2018jun14.patch, #44370
    2018-06-10 sebald Attached File- => Added Window_dropdown_menu_Screenshot_from_2018-06-10_12-40-23.png, #44353
    2018-06-10 philipnienhuis Attached File- => Added Docked_pane_no-pane_border-A.jpg, #44350
        Attached File- => Added Docked_pane_no-pane_border-B.jpg, #44351
        Attached File- => Added Undocked_VE-no_resize_cursor.jpg, #44352
    2018-06-10 philipnienhuis Attached File- => Added Undocked_VE-no_resize_cursor.jpg, #44349
    2018-06-10 sebald Attached File- => Added octave-shortcut_keys_for_gui_widget_dock_undock_close-djs2018jun10.patch, #44348
    2018-06-10 sebald Attached File- => Added octave-windows_7_test_lost_title_bar-djs2018jun09.diff, #44342
    2018-06-08 philipnienhuis SummaryNo more dock button on undocked panes => No more QDockWidget title bar and dock button on undocked panes under Windows
    2018-06-08 philipnienhuis Attached File- => Added bug54078_VE_subpanels_after_undockb-click.PNG, #44327
        Attached File- => Added bug54078_undocked_VE_w_1_undocked_subpanel.PNG, #44328
    2018-06-07 philipnienhuis Attached File- => Added vared_windows_500_no_dock_button.PNG, #44315

    Back to the top


    Powered by Savane 3.3