bugGNU Octave - Bugs: bug #60750, Variable Editor changes docking...

 
 

bug #60750: Variable Editor changes docking state when 'openvar'-ring a variable

Submitted by:  Philip Nienhuis <philipnienhuis>
Submitted on:  Tue 08 Jun 2021 08:39:19 PM UTC  
 
Category:  GUI Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  Ready For Test Assigned to:  Torsten Lilge <ttl>
Originator Name:  Philip Nienhuis Open/Closed:  Open
Release:  dev Operating System:  Any

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)

Mon 14 Jun 2021 04:55:07 PM UTC, comment #25: 

I pushed the following changeset:

http://hg.savannah.gnu.org/hgweb/octave/rev/4c569e386e9b

Marking this bug report as ready to test.  I expect a few more changes with signal/slot connections so that things like the variable editor menu items for plotting can work when there is no main window.

John W. Eaton <jwe>
Project Administrator
Mon 14 Jun 2021 04:01:33 PM UTC, comment #24: 

@Philip: With the current design, you can only start one of these widgets at a time so starting the command window from the GUI wouldn't be possible.  If we do decide to allow starting the command window from the command line (not in GUI mode) then it would just offer another way to enter commands for the interpreter without starting the main window.  If we do make that possible, then the main window is really just a sort of container window that offers menu bars and a place to dock the other widgets.

John W. Eaton <jwe>
Project Administrator
Fri 11 Jun 2021 07:34:08 PM UTC, comment #23: 

[A bit OT]
Just wondering, what would be the effect of starting the command pane from the GUI? or should that not be possible?
Could several panes of the same type be launched? like, 2 file browser panes, or 2 or more doc panes.
If yes I'd envision quite complicated pane management and -maintenance.

The exception is probably the VE with its virtually unlimited nr. of individually undocked subpanes that can be floating around. I use that feature regularly to keep track of what happens inside several arrays when stepping through code. I find it often easier to just undock a VE subpane and move it into a favorable position on the screen than to carefully (if not painstakingly) drag it around to get it to fit somewhere in the VE parent pane.
The only nuisance used to be that undocked VE subpanes just disappear from sight if the undocked VE parent pane went out of focus. But now (? after the fix for bug #60752 ?) I see that they have their own window decorations and remain visible (nice!)

Philip Nienhuis <philipnienhuis>
Project Member
Fri 11 Jun 2021 07:32:48 PM UTC, comment #22: 

> FIXME: WHAT?!?


While trying to fix the issue with the non-restoring horizontal widget position in Qt 5.15 I noticed that one attempt to reset the window layout resulted in a layout that only was "near" to the desired one. It required a second attempt to have the desired layout.

I do not know what happens in Qt internally that prevents the positions of the widgets being restored exactly.

But I don't think that this is the cause of the issue that you are seeing since the main window should be ready when you manually dock the floating widget. Maybe this is related to bug #60646 and the state of the widget is not properly saved when launched from the cli? Btw, did you have a chance to look at the patch attached to comment #13 for closing widgets launched from the cli?

Torsten Lilge <ttl>
Project MemberIn charge of this item.
Fri 11 Jun 2021 06:32:17 PM UTC, comment #21: 

> But I noticed that the workspace widget is empty when launched from the cli and is showing existing variables not before a new variable is set.


I think that is happening because the signal that sends the workspace to the GUI is only sent when the prompt is issued and the workspace has changed.  I suppose we need to also send it when the widget is first created.

There are other issues with signals only being sent when the command line prompt and not when other user interactions occur, for example by pressing a button or interacting with some GUI dialog.

John W. Eaton <jwe>
Project Administrator
Fri 11 Jun 2021 06:23:47 PM UTC, comment #20: 

> I thought I spotted some funny behavior but I cannot reproduce it now.


I've also seen some strange behavior that's not fully reproducible.  For example, opening a widget from the command line, then starting the desktop and docking the existing widget didn't always place the widget back in a tab as I was expecting.

Maybe there is a timing issue?  The following code also seems a bit suspicious to me (I added the WHAT?!? comment):

  void main_window::reset_windows (void)
  {
    // Slot for resetting the window layout to the default one
    hide ();
    showNormal ();              // Unmaximize
    do_reset_windows (false, true, true);   // Add all widgets

    // FIXME: WHAT?!?
    // Re-add after giving time: This seems to be a reliable way to
    // reset the main window's layout
    QTimer::singleShot (250, this, [=] () { do_reset_windows (false, true, true); });
  }

John W. Eaton <jwe>
Project Administrator
Fri 11 Jun 2021 06:18:40 PM UTC, comment #19: 

Re: comment #13.  I guess I'm confused about the meaning of "floating" in this context.  I thought independent windows were "floating" and docked windows (widgets?) were not "floating".  If the concepts of window/widget and floating=true/false are independent, then we have four cases to consider?

John W. Eaton <jwe>
Project Administrator
Fri 11 Jun 2021 05:58:53 PM UTC, comment #18: 

> what is the command for starting the complete gui from the cli?


As in Matlab, "desktop", but it only works if you start Octave with the new terminal widget enabled.

Currently, things are a bit of a mess in this area.  We have "public" functions like openvar and doc that work from the command line to open Qt widgets for editing variables and browsing the documentation and internal functions like "__event_manager_show_file_browser__", "__event_manager_show_command_history__", and "__event_manager_show_workspace__" to open those widgets from the command line.  These internal functions don't currently do the same thing as "filebrowser", "commandhistory", and "workspace".

We also have "__event_manager_edit_file__", but that doesn't work unless the GUI desktop is already running and is not the same as "edit".

Simlarly, "__event_manager_show_preferences__" will open the settings dialog, but only if the GUI desktop is already running.

And, finally, there is "commandwindow" to switch focus to the GUI command window if the GUI desktop is already running.  With the new terminal widget it might eventually be possible to launch that widget from the command line but even if it is possible, I'm not sure that it is something we should do.

My plans are to ultimately provide a more uniform way for all of these widgets to be invoked from the command line interface.

John W. Eaton <jwe>
Project Administrator
Fri 11 Jun 2021 12:20:06 PM UTC, comment #17: 

Thanks for testing.  Let's leave this report open until after a change is pushed.

John W. Eaton <jwe>
Project Administrator
Fri 11 Jun 2021 11:20:48 AM UTC, comment #16: 

Looks to be working fine on Windows as well.
Thanks for fixing.
Will you close this report or shall I do that?

Philip Nienhuis <philipnienhuis>
Project Member
Thu 10 Jun 2021 09:04:50 PM UTC, comment #15: 

On Linux, using patch #3, I think the behavior is what it's supposed to be. I thought I spotted some funny behavior but I cannot reproduce it now.
Tomorrow I'll try on Windows.

Philip Nienhuis <philipnienhuis>
Project Member
Thu 10 Jun 2021 08:40:19 PM UTC, comment #14: 

From some first tests, the patch works well.

But I noticed that the workspace widget is empty when launched from the cli and is showing existing variables not before a new variable is set.

Stupid question: what is the command for starting the complete gui from the cli?

Torsten Lilge <ttl>
Project MemberIn charge of this item.
Thu 10 Jun 2021 08:21:35 PM UTC, comment #13: 

This setFloating (false) was added in the (quite large) changeset http://hg.savannah.gnu.org/hgweb/octave/rev/05a690606fd5

As far as I understand the comment, unparenting a widget in order to have the widget behave like a normal window with all decoration, the widget must not be floating. I remember that it was not that easy to get floating widgets with all window decorations on all platforms. However, the question is if there are scenarios where make_window is called for an already floating window.

Torsten Lilge <ttl>
Project MemberIn charge of this item.
Thu 10 Jun 2021 07:32:23 PM UTC, comment #12: 

I'll give a try, just need some time for building. Tomorrow morning I'll report back.

Philip Nienhuis <philipnienhuis>
Project Member
Thu 10 Jun 2021 04:45:31 PM UTC, comment #11: 

OK, here is one more version.  I think there is still some room for improvement in the way the dock widgets are created and the way the signal connections are managed but it seems to behave the way I expect, at least for the things I tested, including starting the GUI, using the new terminal widget and starting the GUI from the command line, with or without dock widgets open.  If anyone has time to test, I'd appreciate some feedback.  Otherwise, I will maybe do some more cleanup and push some variation of these changes.

(file #51540)

John W. Eaton <jwe>
Project Administrator
Thu 10 Jun 2021 03:52:39 PM UTC, comment #10: 

Oh, I think I found the problem with the double open of the variable editor.  I'm attaching a new version of the patch.

But I still have the question about using setFloating (false) in the make_window function.

(file #51539)

John W. Eaton <jwe>
Project Administrator
Thu 10 Jun 2021 02:52:46 PM UTC, comment #9: 

The attached change almost works for me.  I added a flag to the dock widget to allow checking whether a dock widget already exists when the main window is created.  Then that flag is used to avoid docking widgets that already exist and are adopted by the main window.

But I don't quite get what I was expecting when I try to reset the default layout using the Window -> Reset default layout menu item when there is an adopted dock widget, even though I tried to make that work by adding a "force" option.

And openvar from the GUI command window now creates both a floating and docked widget?!?  That was a surprise.

Anyway, this change shows what I was thinking about by adding a flag to determine whether a dock widget existed before the main_window was created, but there are a lot of interactions here, and I don't fully understand the use of setFloating, especially here in octave_dock_widget::make_window:

    // 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
    if (isFloating ())
      setFloating (false);

Why would we set the floating property to false here?  That doesn't seem to match with making a window and the comment doesn't help me understand.

(file #51538)

John W. Eaton <jwe>
Project Administrator
Wed 09 Jun 2021 07:32:11 PM UTC, comment #8: 

@ttl: Thanks.  I will take another look at this and see whether I can understand what's going on with the unexpected docking/undocking behavior.  I should probably understand how that works anyway..

John W. Eaton <jwe>
Project Administrator
Wed 09 Jun 2021 06:24:48 PM UTC, comment #7: 

comment #6:

> It seems we currently assume that if a dock widget has its parent set to the main_window widget then it is docked and if its parent is nullptr, it is floating.  But is that necessary?  Is it possible for a floating window to have the main_window widget as a parent?


Unparenting a floating widget is necessary in order to get the window decorations. Otherwise the widgets would look like the floating (sub-)dock widgets of the variable editor.

Torsten Lilge <ttl>
Project MemberIn charge of this item.
Wed 09 Jun 2021 02:00:47 PM UTC, comment #6: 

There is definitely some strange behavior with dock widgets since my recent changes to allow them to be opened when Octave is running in command line mode.

I admit I don't fully understand how parenting and docking interact.  It seems we currently assume that if a dock widget has its parent set to the main_window widget then it is docked and if its parent is nullptr, it is floating.  But is that necessary?  Is it possible for a floating window to have the main_window widget as a parent?

My aim for the behavior of these widgets with the new terminal widget is described below (copied from comment #11 of bug #60646).

It should be possible to have the following sequence (the lines marked with ? is the behavior that I would expect but might still be up for debate):

  • open a dockable widget from the command line
  • open the desktop from the command line

   ? any open dockable widgets should remain undocked

  • dock one of the widgets that was initially opened from the command line or undock one that was originally opened (and docked) with the main desktop window
  • close the desktop window and return to the command line

   ? any undocked widgets should remain open
   ? widgets that were originally opened at the command line but were docked when the desktop were closed should be closed with the main desktop window

When restarting Octave in command line mode, no widgets are restored, even if they were open during a previous command line session (maybe that could be configurable, but not opening windows is the default behavior I would expect).

When starting Octave in GUI mode, should the window configuration to be restored from the last time the main window was closed (possibly when returning to the Octave command line) or to the window configuration used in the last "pure" GUI session.  I suppose it is simplest to just save the configuration when the main window is closed and restore that when restarting the main window, whether from a command line session or not.

John W. Eaton <jwe>
Project Administrator
Wed 09 Jun 2021 09:12:56 AM UTC, comment #5: 

Further to comment #3:
(see attached pic, steps 1-3)
Opening a 'subvariable' (field of item of a struct array) of an undocked VE (1) leads to:
(2) docking of the undocked VE, the newly opened subvariable starts as an undocked subpane
(3) after undocking the entire VE pane (clicking the undock button), the initially undocked subpane gets redocked in the now undocked VE pane and the vertical stacking layout of the VE is reset.
See attached .png, it isn't crisp but (I hope) sufficient to illustrate what I wrote above.


Philip Nienhuis <philipnienhuis>
Project Member
Wed 09 Jun 2021 08:36:32 AM UTC, comment #4: 

To clarify: that "other installation" is from the same dev crossbuild from June 1.

Philip Nienhuis <philipnienhuis>
Project Member
Wed 09 Jun 2021 08:34:32 AM UTC, comment #3: 

On one of my other dev Octave installations I find that an undocked VE with some contents, re-docks itself if I "openvar" another variable (actually, I have a struct array open and I double-click on one of some item's field which is a double array).

BTW I find it somewhat amusing rather than annoying. Just one mouse click and it's restored. But it shouldn't behave like that.

I tried if I could find similar behavior with other panes but no, it's just the VE.

Philip Nienhuis <philipnienhuis>
Project Member
Wed 09 Jun 2021 05:33:10 AM UTC, comment #2: 

When in this mode, the only thing that is happening when trying to re-dock is that the VE seems to set its parent from none back to the main window as it looses the title bar.

Torsten Lilge <ttl>
Project MemberIn charge of this item.
Tue 08 Jun 2021 10:44:12 PM UTC, comment #1: 

Same behavior on Linux.  I set Variable Editor (VE) to be a third column on the right.  Next, I typed

x = pi
openvar x

At that point, VE undocked itself.

This behavior does not exist on the stable branch (6.2.0 or 6.2.90).

Rik <rik5>
Project Administrator
Tue 08 Jun 2021 08:39:19 PM UTC, original submission:  

With a dev crossbuild from June 1, when double-clicking some variable in the workspace pane, the docked variable Editor consistently undocks itself (and from then on ignores the "Dock" button and the dock/undock shortcut).

As long as the VE is empty, it behaves as it should w.r.t. docking behavior. But as soon as it contains, or has contained, some variable, its docking behavior detoriates as described above.

I have the VE usually docked above the Workspace in a leftmost pane column; in the middle is the CLI, on the right pane column File browser and History.

Philip Nienhuis <philipnienhuis>
Project Member

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #51530:  bug60750.png added by philipnienhuis (251KiB - image/png)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by ttl (Posted a comment)
  • -email is unavailable- added by rik5 (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 8 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2021-06-14 jwe StatusConfirmed => Ready For Test
    2021-06-10 jwe Attached File- => Added dock-widget-adoption-diffs-v3.txt, #51540
    2021-06-10 jwe Attached File- => Added dock-widget-adoption-diffs-v2.txt, #51539
    2021-06-10 jwe Attached File- => Added dock-widget-adoption-diffs.txt, #51538
    2021-06-09 philipnienhuis Attached File- => Added bug60750.png, #51530
    2021-06-09 ttl Assigned toNone => ttl
    2021-06-08 rik5 StatusNone => Confirmed
        Operating SystemMicrosoft Windows => Any

    Back to the top


    Powered by Savane 3.6