bugGNU Octave - Bugs: bug #53275, Variable Editor: Undocking...

 
 

bug #53275: Variable Editor: Undocking variable window causes it to become nearly full screen

Submitter:  Rik <rik5>
Submitted:  Sat 03 Mar 2018 03:28:49 PM UTC
   
 
Category:  GUI Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sun 11 Mar 2018 08:09:11 PM UTC, comment #21: 

Sorry Dan, I have missed the updated patch. The new patch is pushed with cset
http://hg.savannah.gnu.org/hgweb/octave/rev/5f7b9ee5b878

Torsten Lilge <ttl>
Group Member
Sat 10 Mar 2018 08:46:17 PM UTC, comment #20: 

I recall fixing that.  It looks like the older version of the patch was applied.  (No problem.  I've figured out a way to apply patch differences easily.)  The thing that is missing between the March 5 and March 7 patches is the QFrame.  Attached is a changeset having just that added element and the fixed tooltips.

(file #43507)

Dan Sebald <sebald>
Sat 10 Mar 2018 06:03:03 PM UTC, comment #19: 

Okay, with that sequence I see "Fullscreen undock" as the tooltip as well.

Rik <rik5>
Group administrator
Sat 10 Mar 2018 05:52:32 PM UTC, comment #18: 

Steps to reproduce the (minor) tooltip issue:

  1. Undocking with the fullscreen button
  2. Hover over the updated fullscreen button of the floating widget
  3. It shows "Fullscreen undock" although the button re-docks the widget


Torsten Lilge <ttl>
Group Member
Sat 10 Mar 2018 05:13:09 PM UTC, comment #17: 

@Dan: Thanks a lot.  The new behavior is super cool.  I like the choice to go fullscreen or not.  As the original reporter, this meets my needs so I am marking the bug as fixed.

@Torsten: The tootlip correctly shows "dock" for me when I do the following


./run-octave -f
x = magic (3);
openvar x
# Click on "Undock Fullscreen" button
# Hover over "Dock" button



Rik <rik5>
Group administrator
Sat 10 Mar 2018 02:37:36 PM UTC, comment #16: 

Dan, thanks for the patch. I have pushed it with cset
http://hg.savannah.gnu.org/hgweb/octave/rev/8ce66fe46f18

One thing that might be improved: When already undocked in fullscreen, the tool tip of the new button still says "undock".

Torsten Lilge <ttl>
Group Member
Thu 08 Mar 2018 08:54:32 AM UTC, comment #15: 

OK, this changeset is ready.

I like the look and the coding approach is fairly straightforward.  I added a QFrame to the variable panels without it serving as a container but instead handle sizing along with the variable_editor_widget resize event:


+    // Custom title bars cause loss of decorations, add a frame
+    m_frame = new QFrame (this);
+    m_frame->setFrameStyle (QFrame::Box | QFrame::Sunken);
+    m_frame->setAttribute (Qt::WA_TransparentForMouseEvents);



+  void variable_dock_widget::resizeEvent (QResizeEvent *)
+  {
+    if (m_frame)
+      m_frame->resize (size ());
+  }


I chose the sunken frame because I felt it a little more subtle as far as delimiting subpanels.  The non-sunken line matched the table boundary which gave the illusion of a very thick single line.  See attached screenshots.  At first I was going to turn the QFrame off when in docked non-floating mode, but then I sort of liked the appearance of the subtle frames.

I used resource_manager::icon() for the icons I added, but I left the close button as is.  To use the close button in resource_manager::icon() would require renaming those couple buttons in libgui/src/icons to match the FreeDesktop naming convention.

Perhaps the fullscreen/restore icon choice could be different.  E.g., use the same icon that is a '+' on my system, but I don't know what that would be called.  Nonetheless, the appearance and behavior are now what I had imagined, and I'll leave any further mods to Torsten.

(file #43487,

Dan Sebald <sebald>
Wed 07 Mar 2018 07:43:53 PM UTC, comment #14: 

Reply to comment #12:

It's a Catch-22: Add buttons for GUIs that don't have a close and be redundant in GUIs that do, or have no buttons for some GUIs.  What about the other actions like "minimize" and "maximize"?  Does Windows have those, but no "close" button?

Reply to comment #13:

I'll add a note explaining the extra title-bar removal and reparenting is a KDE thing.  That sure seems like an "undocumented behavior" reliance.  I've seen KDE, but never used it for extended periods.  Why does it not have some of the action controls, and should that be something in Octave GUI's purview?

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

Yes, such an annoyance this is.  This means that none of the color CSS styles regarding border apply to the floated variable-editor panels.  OK, then use a QFrame...but the QDockWidget has the added title-bar above the setWidget() that it encapsulates so how can one put a frame around the whole thing?  Multiply inherit a QDockWIdget and QFrame?  Messes with the MOC table.  Oy.

Dan Sebald <sebald>
Wed 07 Mar 2018 07:07:29 PM UTC, comment #13: 

Reply to comment #11:

From 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."

The unparenting wihtout title bar widget is necessary to get the floating widget being resizable (or movable via alt+left mouse, I can't remember) with KDE Oxygen.

Torsten Lilge <ttl>
Group Member
Wed 07 Mar 2018 06:52:14 PM UTC, comment #12: 

Reply to comment #10:

"One thing we could do is take out the redundant close button when the window is floated. It's odd to have a close button essentially right next to another close button. Then there would be just the fullscreen and redock icons on that line."

Well, no. On window managers which do not add a normal window title bar for unparented floating widgets, there would be no close button at all.


Torsten Lilge <ttl>
Group Member
Wed 07 Mar 2018 09:00:37 AM UTC, comment #11: 

@Torsten: Do you see why the following three (commented-out) lines were added?  As I understand the Qt documentation, all that needs to be done is set the parent to zero:


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


Works fine here without those lines.

Dan Sebald <sebald>
Wed 07 Mar 2018 07:19:47 AM UTC, comment #10: 

"Listing all the elements separately instead of just using Qt::Window together with parent 0 was one attempt to get full decoration in KDE Oxygen."

Oh, that makes sense.  Just a simple oversight and easy fix.  I will add the flag to this patch.

Any widget that has a parent of 0 takes on the characteristics of a system window (see Qt::Widget and Qt::Window):

http://doc.qt.io/qt-5/qt.html#WindowType-enum

and those are the controls necessary for desktop task-bar functionality, etc.

QDockWidget and its title bar is a Qt construct, I think.  Goes along with the Central Widget QMainWindow.  That's why the title bar can be replaced by a custom one--that title bar isn't a window-manager title bar.

Yeah, I don't think it is worth the effort to replicate the title bar of windows intended to be window-managed-windows (i.e., can minimize to the task bar).  Having another item in the pseudo window-manager title bar might be confusing in itself because no other applications have such a thing.

One thing we could do is take out the redundant close button when the window is floated.  It's odd to have a close button essentially right next to another close button.  Then there would be just the fullscreen and redock icons on that line.

Also, I added a border to the floated variable-editor panels easy enough.  That helps.  I'll add that to this patch as well.

Dan Sebald <sebald>
Wed 07 Mar 2018 06:10:26 AM UTC, comment #9: 

The fromTheme framework together with the fallback option is in use since long time in the octave GUI:
http://hg.savannah.gnu.org/hgweb/octave/file/578ebece3dc7/libgui/src/resource-manager.cc#l334

Sure, we can provide a maximize button, too. Listing all the elements separately instead of just using Qt::Window together with parent 0 was one attempt to get full decoration in KDE Oxygen.

And yes, floating dock widgets from the main window should have the look and feel of separate windows with conventional elements for closing, moving etc. (especially now, where other floating widgets from VE exist). Moreover, they must not stay on top of the main window as floating dock widgets generally do.
Therefore, when we really would drop the conventional window title bar (I do not think that this is really necessary), the remaining title bar should be styled in a way for clearly distinguishing these widgets from ordinary floating widgets.

Torsten Lilge <ttl>
Group Member
Tue 06 Mar 2018 11:22:44 PM UTC, comment #8: 

fromTheme was introduced in Qt 4.6:

http://doc.qt.io/archives/qt-4.8/qicon.html#fromTheme

so there shouldn't be any issue in terms of compilation.  There is a fallback icon as an input in case the platform doesn't supprot theme icons.

I did quite a bit of reading last night and now understand that the system window manager flags are the only means of modifying the window's title bar.  That is, there are no widget's associated with the title bar.  Just curious, why is it that the maximize button is not included, i.e.,:


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


If I change that to simply Qt::Window flags, there is the common maximize button (+) that will expand/shrink to/from full screen.  Most applications have that and it is pretty handy.

It's not an easy thing to remove a QWindow title bar (Qt::Window | Qt::CustomizeWindowHint) because then all of the mousing, etc. no longer works and has to be implemented manually.  I actually think Octave currently is doing something out of the ordinary to get the Window Manager title bar on a QDockWidget.  As Torsten pointed out, we could use setTitleBarWidget (i.e., octave_dock_widget) and add maximize/minimize controls there.  I can't seem to find a means of getting the Window Manager style information though.

Regarding question 3, I think the frame around the undocked variable panels can be easily corrected with the use of style sheets:

http://doc.qt.io/archives/qt-4.8/stylesheet-examples.html#customizing-qdockwidget

It's simply that the application style sheet is generically copied to the newly created QDockWidgets and the frame border is probably 0px.

Dan Sebald <sebald>
Tue 06 Mar 2018 06:34:05 AM UTC, comment #7: 

The QIcon::fromTheme framework is used for all other icons of the GUI but not all platforms are supporting this. For the dock widgets the icnos were designed in order to look similar to the ones that qt uses for dock widgets.

The light version of the close/dock button icons is for darker colors of the title bar. The icons (black or white) are automatically chosen depending on the title bar color. I think this is something that QIcon::fromTheme does not provide.


Torsten Lilge <ttl>
Group Member
Tue 06 Mar 2018 04:41:36 AM UTC, comment #6: 

I've programmed a fullscreen action/button into the variable editor panels in a way that I like.  Please test.  How about we implement this and then later developers can modify to something else if desired.  That way we can close the bug report.

It should be ready to go, except there may be some adjustment based on the following set of questions (or these could be left for addressing elsewhere individually).  Primarily for Torsten:

1) I've implemented the new icon by using the following "quasi-standard" definitions:


QIcon::fromTheme ("view-fullscreen")
QIcon::fromTheme ("view-restore")


The above route is intended for matching the look-and-feel of the operating system GUI.  It's advantage is that the icons come from the system so I didn't have to add any icon in libgui/src/icons such as:

libgui/src/icons/widget-close-light.png
libgui/src/icons/widget-close-light.svg
libgui/src/icons/widget-close.png
libgui/src/icons/widget-close.svg
libgui/src/icons/widget-dock-light.png
libgui/src/icons/widget-dock-light.svg
libgui/src/icons/widget-dock.png
libgui/src/icons/widget-dock.svg
libgui/src/icons/widget-undock-light.png
libgui/src/icons/widget-undock-light.svg
libgui/src/icons/widget-undock.png
libgui/src/icons/widget-undock.svg

In theory, we could get rid of the above icons and use some of the definitions here:

https://specifications.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html

I tried

QIcon::fromTheme ("window-close")

as a replacement for libgui/src/icons/widget-close.png and it is a thicker X but it appears to match what one might see in other applications like FireFox or the system monitor and so on.  Should we look into changing those?  Or just wait and see if others run into problems with a missing fullscreen/restore icon?

2) Also notice that for the main window, and generally for windows in the wider system, that the titlebar icons are usually a light gray and only become black when the cursor hovers above them.  I see in the icon list in ligbui/src/icons there is a "light" version so perhaps that's what the other icon was intended for but never implemented.  However, I suspect that Qt may have a means of lightening an icon in the general sense.  So should we attempt to make the icons in the added titlebars behave in a similar way, i.e., light gray until cursor hovers over them and they become the dark icons as in the attached patch?

3) With the patch, if one selects the "undock" QToolBar the panel will pretty much float right where it is.  I personally get confused by that, maybe because of the lack of a frame on the floated QDockWidget.  Should I see if there is some type of flag that will put a frame around the floated window?

4) The tooltip for the new fullscreen QToolButton will dynamically change based upon whether something is docked, e.g., "Fullscreen undock" vs. "Fullscreen".  Pay attention to those and see if they make sense.  But also, check out the tooltips for the adjacent QActions.  They have "widget" within them, e.g., "Dock widget" and "Close widget".  Does the "widget" add anything?  Should we get rid of that word?  The user doesn't need to know these are called widgets.

(file #43471)

Dan Sebald <sebald>
Mon 05 Mar 2018 10:33:16 PM UTC, comment #5: 

We'll experiment with the multiple header issue.  These sorts of changes are only a few lines of code, so it's not much effort.

I did a small search the other day, and there are people who wondered about KDE's maximize/minimize/close buttons

http://linuxbsdos.com/2012/07/04/how-to-custmize-kdes-window-titlebar-buttons/

It looks like it may be a configurable option.  My hope is that Qt has this all figured out for KDE and that the existence of the title and titlebar buttons is simply a matter of the default settings being off depending on how the system GUI is configured but still manageable via Qt.

For now, I'll keep this a separate issue.

Dan Sebald <sebald>
Mon 05 Mar 2018 06:04:12 PM UTC, comment #4: 

Dan, as mentioned in the other bug report, some window managers like KDE with Oxygen style do not put a normal window decoration (including title bar) around floating dock widgets (even though they are reparented). That's why I think that is not possible to drop the inner header line. Otherwise, there would be no control at all.

Torsten Lilge <ttl>
Group Member
Mon 05 Mar 2018 06:41:04 AM UTC, comment #3: 

Torsten pointed out what controls the presence of minimize/maximize buttons, so I will experiment with this while attempting to remove the redundant header line when octave_dock_widgets are floated.

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

Dan Sebald <sebald>
Sat 03 Mar 2018 08:46:24 PM UTC, comment #2: 

Yes, I put that behavior in on purpose, knowing that it would evolve into something else.  This was for a couple reasons.  First, I didn't like that pressing the undock icon/button in the upper right corner would make the undocked window the exact same size right on top of where it was.  One couldn't tell that anything happened when in fact it did undock.

So, I thought I could make the undocked pane a certain default size, centered or something.  What to do?  But then I also thought that something users would like to do is expand the tiny docked window for a quick look at the table in a much wider view, and then press a button and put it back to the small size.  So, this behavior is just meant to illustrate that idea.

We can take this out easy enough:


        // Make initial size expanded very large for "magnified" viewing
        if (m_initial_float)
          {
            // This will be resolved based on user feedback and preference
            // and will eventually work without QGuiApplication.  Perhaps
            // a maximize button added to the label_dock_widget windows
            // along with the dock/undock and close buttons is best.
#if defined (HAVE_QGUIAPPLICATION)
            QScreen *pscreen = QGuiApplication::primaryScreen ();
            QRect rect (0, 0, 0, 0);
            rect = pscreen->availableGeometry ();
            rect = QRect (rect.x () + 5, rect.y () + 5,
                          rect.width () - 10, rect.height () - 10);
            setGeometry (rect);
            m_initial_float = false;
#endif
          }


but the big question is what should the behavior be for best general use?  What would user's prefer?  Perhaps this sort of thing can be discussed at OctConf.  My thinking is that we'll end up putting some kind of "fullscreen" or "maximize" button alongside the dock/undock button, but I didn't want to go down that path without getting user feedback and getting back to a stable location because cleanup and better structure of the V.E. classes was a part of this, which JWE is working on.

Dan Sebald <sebald>
Sat 03 Mar 2018 05:01:26 PM UTC, comment #1: 

Confirmed, this is the case for one or two weeks now.

In my experience the full-screen undocking can be often avoided by first dragging the tab to the left-bottom corner (or just to the bottom) of the variable-editor pane, and as soon as it shows there as a reasonably-sized widget it can be dragged to the desktop where it retains the reasonable size.

Philip Nienhuis <philipnienhuis>
Group Member
Sat 03 Mar 2018 03:28:49 PM UTC, original submission:  

The new Variable Editor allows individual variables to be undocked and moved around as windows.  This may be a KDE issue, but when I undock a small variable, such as a scalar, the resulting window is nearly the entire size of my screen.  See the attached screenshot.

The code was simply:


x = 1;
openvar x
# Undock x variable



Rik <rik5>
Group administrator

 

(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 rik5 (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 9 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-03-10 sebald Attached File- Added octave-ve_frame_and_tooltips-djs2018mar10.patch, #43507
    2018-03-10 rik5 StatusConfirmed Fixed
        Open/ClosedOpen Closed
    2018-03-08 sebald Attached File- Added octave-ve_improved_fullscreen-djs2018mar07.patch, #43487
        Attached File- Added Box_Screenshot_from_2018-03-07_17-18-45.png, #43488
        Attached File- Added Box_Sunken_Screenshot_from_2018-03-07_17-21-20.png, #43489
    2018-03-06 sebald Attached File- Added octave-ve_improved_fullscreen-djs2018mar05.patch, #43471
    2018-03-03 philipnienhuis StatusNone Confirmed
    2018-03-03 rik5 Attached File- Added var_editor_screen_sz.png, #43444

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code