bugGNU Octave - Bugs: bug #38785, GUI / Windows: undocked panes are...

 
 

bug #38785: GUI / Windows: undocked panes are always on top of GUI

Submitted by:  Philip Nienhuis <philipnienhuis>
Submitted on:  Sat 20 Apr 2013 05:07:45 PM UTC  
 
Category: GUISeverity: 3 - Normal
Priority: 5 - NormalItem Group: Regression
Status: FixedAssigned to: None
Originator Name: Philip NienhuisOpen/Closed: Closed
Release: devOperating System: Microsoft Windows

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

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

 

(Jump to the original submission Jump to the original submission)

Fri 21 Jun 2013 08:46:18 PM UTC, comment #19:

fixed with changeset
http://hg.savannah.gnu.org/hgweb/octave/rev/d749c9b588e5

Torsten <ttl>
Project Member
Tue 18 Jun 2013 08:00:54 PM UTC, comment #18:

AFAIK there is no way to manipulate the title bar. The window decoration is handled by the window manager.

Hiding the subtitle bar would hide the undock-button, too. There would be no way to dock the widget again.

In the meanwhile I played around with saving and restoring geometries. When a widget becomes floating the last floating geometry can be restored. But still no solution for restoring the geometry of a docked widget.

If there are no other objection I will tidy up the patch and push it.

Torsten <ttl>
Project Member
Tue 18 Jun 2013 07:33:14 PM UTC, comment #17:

You hit it on the nose, Torsten, that was the original bug report, thanks.

Reading back I cannot recall whether I only tested on Linux. I think I haven't been able to build the GUI since mid-2012 or earlier, only when MXE came (around Xmas) I could build it again.
So I'd say bug #37190's fix has never been tested on Windows.

I just finished an MXE build with your patch (comment #12) and it works OK on Windows.
Admittedly having to dock panes in two steps may be a tiny bit clumsy but the advantage of the GUI no more being covered by undocked panes outweighs this by far. IMO.
Maybe later on this docking behavior can be optimized; for now at least I am happy with it :-) Thanks so much!

A side note: undocked widgets have both a close button and a "hide pane" button which do more or less the same thing (not to mention a title bar and a subtitle bar). I think the "hide pane" button can be dropped as can the subtitle bar.

Would it be possible to add the pane manipulation buttons to the main title bar? (Could also be a future optimization)

Philip Nienhuis <philipnienhuis>
Project Member
Tue 18 Jun 2013 05:50:23 PM UTC, comment #16:

Maybe you refer to bug #37190.

Torsten <ttl>
Project Member
Tue 18 Jun 2013 04:28:18 PM UTC, comment #15:

Maybe I was mistaken, and it was fixed on Linux only; I cannot find the relevant thread. It may be even from last summer or so.

I'll try your patch later tonight and will report back.

Philip Nienhuis <philipnienhuis>
Project Member
Tue 18 Jun 2013 05:09:12 AM UTC, comment #14:

It would be very interesting to know with which build this worked in windows.

The position can be stored in the settings but it is not possible to add a dockwidget at a specific position, only into a specific dock area. A resize of the widget after docking should be possible (from the qt docs) by resizing the child of the dock widget but I didn't get that to work (and from the internet, I am not the only one).
One could store state and geometry of the main window and recover that when re-docking if nothing changed in the meantime.

Torsten <ttl>
Project Member
Mon 17 Jun 2013 09:45:30 PM UTC, comment #13:

It did work properly for a while (I believe during Octave 3.7.1 - 3.7.3 or so).
What has changed so that it became so much more difficult? (hmm does that matter anyway)

Could the previous docked-widget positions be backed up somewhere and re-used, so that an undocked pane can be re-docked in the old position? If another pane gets undocked/docked in the mean time the backup should be discarded, of course. Did you already explore that in comment #11?

Philip Nienhuis <philipnienhuis>
Project Member
Mon 17 Jun 2013 05:31:37 PM UTC, comment #12:

Attached a patch with a possible solution to this problem:

  • The title bar of each QDockWidget is replaced by a custom one with buttons for closing and (un)docking.
  • When undocking (by means of the new button), the widget is re-parented to 0 which makes it an independent window.
  • When re-docked, it is re-added to the main-window.

The new mechanism needs some changes in storing position and size in the settings and several changes because parent () does not work anymore when the widget is floating (has no parent).

Drawbacks (so far):

  • When re-adding, the widget is really handled as a new dock-widget and is not added at its old place.
  • Dragging a dock widget only works for changing the dock location. It can not be dragged outside the main window to make it floating (the qt floating mechanism is disabled since once a widget is dragged, it would become floating and would be reparented to 0 and the main window is not aware of it anymore and it can not be dropped into the main window again).
  • From above, it directly follows that a floating window can only be re-docked by the (un)dock button, not by dragging it into the window. Re-docking to a desired position has to be done in two steps: Re-adding with the button, then dragging the docked window into the desired position.

The patch is also available at bitbucket:
https://bitbucket.org/ttl/octave-ttl/commits/c64bfd36dc5ddab8de16172d9fa159d76c1b416a

(file #28336)

Torsten <ttl>
Project Member
Fri 14 Jun 2013 05:06:20 AM UTC, comment #11:

A short interim report:
I have found out that in windows, floating dock-widgets only behave like stand-alone windows if the parent of the widgets is removed (setParent (0)). But since the "connection" between main window and widget then is lost some problems arise. Up to now I did not find a way to re-dock a floating widget at the old position (it has to be added as a new dock widget) or to save the widgets state in the settings for the next program start.

Torsten <ttl>
Project Member
Tue 23 Apr 2013 02:40:48 AM UTC, comment #10:

How would someone know to double click the title bar to dock the window? It certainly did not occur to me to try that.

John W. Eaton <jwe>
Project Administrator
Mon 22 Apr 2013 07:58:39 PM UTC, comment #9:

On windows, a double click on the title bar of a floating dock widget docks it even in our case where the flag was set to Qt::Window. I guess this is why there is no more float-button (in ubuntu, a double click maximizes the window).

Torsten <ttl>
Project Member
Sun 21 Apr 2013 01:53:14 PM UTC, comment #8:

Yes, I see this "additional" title bar in ubuntu, too. It seems that the title bar of a docked widget is preserved when floating and the common title bar is added when setting the Qt:Window flag. On windows we only have the common title bar which slightly changes the behaviour for different window flags.

On windows, if the state of a floating widget is not changed from Qt:Widget to Qt:Windows then a double click on the title bar docks the widget.

Torsten <ttl>
Project Member
Sun 21 Apr 2013 01:47:33 AM UTC, comment #7:

I have also noticed that the floating widgets on my Debian system have a line at the top with a title, an overlapping windows icon that can be used to dock the window, and an [x] icon that can be used to close the window. That is missing in my Windows build. If there is no way to get this feature on the Windows build, can we at least add a button that can be used to dock the window?

John W. Eaton <jwe>
Project Administrator
Sat 20 Apr 2013 10:18:12 PM UTC, comment #6:

My apologies, I misunderstood the problem and got confused by the fact that the problem had "resurfaced".

Michael Goffioul <goffioul>
Project Member
Sat 20 Apr 2013 09:58:47 PM UTC, comment #5:

Altering the window flags is currently done:

This works on Linux but apparently not fully on windows (a normal title bar is generated for the floating widget but it is not treated as independent window.

Torsten <ttl>
Project Member
Sat 20 Apr 2013 09:53:23 PM UTC, comment #4:

That behavior is the default for dock widgets in Qt. IIRC, the trick to work around it was to catch the event when a dock widget is being made floating and adapt the dock widget: either reparent it into a regular window, or alter widget flags (I don't remember exactly).

Michael Goffioul <goffioul>
Project Member
Sat 20 Apr 2013 09:41:42 PM UTC, comment #3:

Okay, the test was not successful.

The floating widgets are still on top of the main window without a separate icon when using alt+tab. I tried to fix this with the additional windows flag Qt::MSWindowsOwnDC.

It is possible to use ctrl-1 ... -5 to switch to other widgets except when the command window has the focus, then the shortcuts do not work. What is the behaviour of the original version here? (Annoyingly I have overwritten this version on my windows machine).

Torsten <ttl>
Project Member
Sat 20 Apr 2013 06:30:42 PM UTC, comment #2:

AFAICS any restart of ./mk-dist clears the tmp & octave & dist dirs where Octave's sources & built blocks are located.

[Slightly OT]
Just for comparison: on my 2.5 Ghz Core Duo a two-daily update of Octave itself usually takes 5-10 minutes, an ensuing MXE-build (just Octave + packaging the dist archive) around .5 - 3/4 hour. Including make dist (5 mins.), preparation of MXE (SHA1, etc), file transfer to Windows, rebooting to WinXP and setting it up there it takes around 1.5 hours altogether.

But most of this happens in the background while I'm doing other work, that's why I could regularly build MXE the last weeks.

I think cmake is somehow involved, and I barely understand configure-("classic")make. So no, I doubt if there's an easy way to cut down on MXE development time.

Philip Nienhuis <philipnienhuis>
Project Member
Sat 20 Apr 2013 05:46:40 PM UTC, comment #1:

Confirmed with a mxe build of the recent default branch. In addition, floating widgets are not working as independent windows (e.g alt+tab does not work) and Ctrl-1 ... Ctrl-5 are not working for activating the widgets. Only Ctrl-0 for the command window is working.

I have an idea what might be the reason and am currently working on a patch. It will take some time to rebuild the mxe version and test it. Is there a way to just rebuild changed files in the mxe build?

Torsten <ttl>
Project Member
Sat 20 Apr 2013 05:07:45 PM UTC, original submission:

An old problem has resurfaced with the MXE builds:

Undocked panes (e.g., editor) always appear on top of the GUI window, even if the focus is on the GUI and not on that pane
(e.g., I can type commands in the docked terminal while the undocked editor pane partly overlies that terminal window.)

Philip Nienhuis <philipnienhuis>
Project Member

 

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

Attach File(s):
   
   
Comment:
   

Attached Files
file #28336:  floting_docks_v01.patch added by ttl (17kB - text/x-diff)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by jwe (Posted a comment)
  • -unavailable- added by goffioul (Posted a comment)
  • -unavailable- added by ttl (Posted a comment)
  • -unavailable- added by philipnienhuis (Submitted the item)
  •  

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

    Only project members can vote.

     

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

     

     

    Follow 6 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Fri 21 Jun 2013 08:46:18 PM UTCttlStatusReady For Test=>Fixed
      Open/ClosedOpen=>Closed
    Tue 18 Jun 2013 08:00:54 PM UTCttlStatusPatch Submitted=>Ready For Test
    Mon 17 Jun 2013 05:31:37 PM UTCttlAttached File-=>Added floting_docks_v01.patch, #28336
      StatusConfirmed=>Patch Submitted
    Sat 20 Apr 2013 05:46:40 PM UTCttlStatusNone=>Confirmed

    Back to the top


    Powered by Savane 3.1-cleanup