The docks3 branch is ready for testing

[Edward K. Ream]

This branch is my attempt at #1665. #1666 is the corresponding PR.

This was tricky code to get right, but the result is slightly simpler than the old. As noted in #1665, Leo no longer uses an "empty" cache key to represent new files. Instead, new files get the layout of the first-loaded .leo file. When someone loads Leo for the very first time (.leo/db is empty), Leo will use one of two reasonable defaults.

The new code passes my limited tests. Please test the docks3 branch and report any problems. I won't merge this branch into devel until Thomas is happy.

Note: The docks3 branch is the only remaining dock-related branch. All other branches have been merged into devel or deleted.

Edward

[Thomas Passin]

On Sunday, September 13, 2020 at 6:24:31 AM UTC-4, Edward K. Ream wrote:

This branch is my attempt at #1665. #1666 is the corresponding PR.

This was tricky code to get right, but the result is slightly simpler than the old. As noted in #1665, Leo no longer uses an "empty" cache key to represent new files. Instead, new files get the layout of the first-loaded .leo file. When someone loads Leo for the very first time (.leo/db is empty), Leo will use one of two reasonable defaults.

The new code passes my limited tests. Please test the docks3 branch and report any problems. I won't merge this branch into devel until Thomas is happy.

Not yet happy:  with --use-docks, a new outline opens with the default layout, not with the layout of the first open outline. See attached screen prints.

Leo 6.3-devel, docks3 branch, build cb98386efa
2020-09-13 07:13:05 -0500
Python 3.8.2, PyQt version 5.15.1
Windows 10 AMD64 (build 10.0.18362) SP0

[Edward K. Ream]

On Sun, Sep 13, 2020 at 7:58 AM Thomas Passin <tbp1...@gmail.com> wrote:

 

Not yet happy:  with --use-docks, a new outline opens with the default layout, not with the layout of the first open outline.

Thanks for your continued testing.  I have improved my testing, and I see that you are correct.

It appears that despite calling dw.restoreState (with the correct dw), all outlines open with the default state, except the very first outline. I'm not sure what, if anything, can be done. Just now I am stumped.

Edward

[Thomas Passin]

I don't see how I can help with that as yet - I'm clueless about how the code works.

[Thomas Passin]

According to this, before calling restoreState(), restoreGeometry() should be called -

https://doc.qt.io/qt-5/restoring-geometry.html

I don't see the geometry being saved or restored anywhere.  (I found this link by searching for "qt5 restoreState").

[Edward K. Ream]

On Mon, Sep 14, 2020 at 12:15 PM Thomas Passin <tbp1...@gmail.com> wrote:

According to this, before calling restoreState(), restoreGeometry() should be called -

https://doc.qt.io/qt-5/restoring-geometry.html

Good catch. It's a starting point. Having said that, I don't think window geometry is the issue.

I'm pretty clueless about the Qt docks code myself. Leo is creating a new QMainWindow for every outline. (Each DynamicWindow is a subclass of QMainWindow). That may be causing problems, maybe even exposing a latent Qt bug.

There is a lot of cruft in the docks-related code. Recent code has (supposedly!) changed over to using a single set of global Qt docks.

The next step will be to see whether using a single QMainWindow might make more sense.

Edward

[Thomas Passin]

On Monday, September 14, 2020 at 3:09:00 PM UTC-4, Edward K. Ream wrote:

 Leo is creating a new QMainWindow for every outline. (Each DynamicWindow is a subclass of QMainWindow). That may be causing problems, maybe even exposing a latent Qt bug.

...

The next step will be to see whether using a single QMainWindow might make more sense.

 I have always assumed that there is just one main window.   Is each of Leo's dynamic windows a class that contains its own outline, docks, body, nav/log/find etc. panes?

[Thomas Passin]

in app.saveWindowState, there is this bit:

val = base64.encodebytes(val).decode('ascii')

This ought to be equivalent to 

val_str = val.decode()

UTF-8 is the implied encoding, which will work for all-ascii bytes.  Or if the QT5 decoding actually is base64, then just use that as the argument of decode().

val is returned by QT5 as a C++ byte array.  I don't know whether pyqt5 turns that into a Python bytearray or a Python bytes object, but either should decode as above.

Not that this would solve the current issue :)

[vitalije]

I'm pretty clueless about the Qt docks code myself. Leo is creating a new QMainWindow for every outline. (Each DynamicWindow is a subclass of QMainWindow). That may be causing problems, maybe even exposing a latent Qt bug.

There is a lot of cruft in the docks-related code. Recent code has (supposedly!) changed over to using a single set of global Qt docks.

I have tried docks once and gave up them shortly. This morning I decided to look at them again and try to help with this issue (if I can).

Initial look was awful. Then it was too easy to mess up docks so much that the layout become totally unusable. I very much dislike clearing my cache because I keep there some data important for my work process, so I tried to delete only entries related to dock layout using script. But, those entries are saved again when closing Leo and they are saved in unmanageable state again. I had to delete entries using script and then to kill Leo, to start again with the default layout. Then I realized that in order to achieve my usual layout (like the one I use without docks: body on the right side from top to bottom, and on the left outline above tabs), I have to change setting @string central-dock-widget=body. Once I added this setting and restarted Leo, layout got broken again because saved layout had different central widget. When I finally managed to adjust layout to my liking, I have saved and closed Leo. On the next start layout was well preserved, but hitting Ctrl-n (new outline), I got again default layout, not the copy of first open Leo layout. This is most likely because setting central-dock-widget was local to the first file, and new outline got the default value for this setting and therefore the layout of the first loaded outline can't be applied.

I would be really surprised if a newbie had enough patience and commitment to adjust the initial layout to something usable.

Then I compared docks and no-docks Leo window. The only difference is that in docks all three panes (outline, body and tabs) have small label above. In effect it reduces useful screen space. So, I wander what are the reasons that one would prefer docks over no-docks layout.

Can anyone who uses docks and prefer docks explain me what are the benefits of using docks? Perhaps I miss something and I am not using them correctly.

Anyway, I think that it isn't enough to have just single hard-coded value in app.defaultWindowState. If this state can't be applied when central-dock-widget isn't the same as was used in this hard-coded value. There should be hard-coded value for each possible value of central-dock-widget. Perhaps these values might be stored in the theme files. There should be a command to launch a dialog for selecting one of the predefined layouts. If one messes up docks layout, this command should allow easy restoring layout to something usable.

It might be useful to have a command which would add current layout to the list of predefined layouts (that can be selected from the dialog) and a setting which one should be used for new outlines.

Unless I learn about some feature of the docks interface that makes it superior over the no-docks interface, I will stick to the no-docks interface.

Vitalije

[Edward K. Ream]

On Tuesday, September 15, 2020 at 2:15:56 AM UTC-5, vitalije wrote:

> I have tried docks once and gave up them shortly. This morning I decided to look at them again and try to help with this issue (if I can).

Thank you! I would appreciate your help. I've been trying to get by with small patches. Clearly, that approach has failed.

> Initial look was awful. Then it was too easy to mess up docks so much that the layout become totally unusable. I very much dislike clearing my cache...[big snip]

I think the present unsatisfactory state of affairs allows us to consider a thorough redesign. We could also abandon docks entirely.

 > I would be really surprised if a newbie had enough patience and commitment to adjust the initial layout to something usable.

Yes, we are all agreed on this point.

> Then I compared docks and no-docks Leo window. The only difference is that in docks all three panes (outline, body and tabs) have small label above. In effect it reduces useful screen space. So, I wander what are the reasons that one would prefer docks over no-docks layout.

Docks can be floated, which might be useful when using multiple monitors. Perhaps this is dock's major advantage. Docks are also necessary for the pyzo_in_leo plugin, but I would be willing to abandon that plugin.

> Anyway, I think that it isn't enough to have just single hard-coded value in app.defaultWindowState.

Good point. Another option would be to use the outline dock as the only possible central widget.

> It might be useful to have a command which would add current layout to the list of predefined layouts (that can be selected from the dialog) and a setting which one should be used for new outlines.

I would prefer not to rely on yet another command that everyone, including newbies, must be aware of.  That said, your suggestion is a possibility.

> Unless I learn about some feature of the docks interface that makes it superior over the no-docks interface, I will stick to the no-docks interface.

Thank you for these comments. They are most helpful. I am beginning to think that qt docks and the pyzo_in_leo plugin were a dead end. There have been other dead ends in Leo's past. I've never regretted killing failed projects and moving on.

Options

Here are the possible actions we could take. Not all these are mutually exclusive:

- Abandon support for Qt docks, and retire the pyzo_in_leo plugin.

- Use a single QMainWindow when using docks.

- Always use the outline as the central widget.

- Provide default layouts for all possible central widgets.

Summary

Some people apparently would benefit from using Qt docks, but at present Qt docks are unusable except in those use cases where qt docks and Leo's legacy gui are virtually the same.

The simplest thing that could possibly work would be to abandon support for Qt docks entirely. I am leaning in that direction. The pyzo_in_leo plugin would be abandoned.

Imo, if we do retain Qt docks, a thorough design review will be essential. Imo, the design of pyzo's layout would likely be a good starting point. Very likely, we should abandon docks if that design won't work.

Your comments are very important. Please let us all know what you think.

Edward

[Edward K. Ream]

On Mon, Sep 14, 2020 at 2:56 PM Thomas Passin <tbp1...@gmail.com> wrote:

The next step will be to see whether using a single QMainWindow might make more sense.

 I have always assumed that there is just one main window.   Is each of Leo's dynamic windows a class that contains its own outline, docks, body, nav/log/find etc. panes?

Yes. As always in Leo, switching between outlines also switches log panes. I don't want to change this. There would likely be too many subtle side effects.

I have no memory of my thought processes when doing the dock-related code. I won't even pretend to defend the choices I made. Many of those "choices" were likely just code-related hacks.

Edward

[Edward K. Ream]

On Mon, Sep 14, 2020 at 3:02 PM Thomas Passin <tbp1...@gmail.com> wrote:

in app.saveWindowState, there is this bit:

val = base64.encodebytes(val).decode('ascii')

This ought to be equivalent to 

val_str = val.decode()

UTF-8 is the implied encoding, which will work for all-ascii bytes.  Or if the QT5 decoding actually is base64, then just use that as the argument of decode().

The code above is taken directly from pyzo. A simpler way may be possible, but any such simplification will have no effect on the big questions we are facing.

Edward

[vitalije]

Docks can be floated, which might be useful when using multiple monitors. Perhaps this is dock's major advantage. Docks are also necessary for the pyzo_in_leo plugin, but I would be willing to abandon that plugin.

It is possible to have outline, body and tabs in separate top level windows in no-docks. Just right click on the split line and choose "openWindow" then any widget you want and it will be displayed in the separate top level window that can be moved to the different monitor.

 

Good point. Another option would be to use the outline dock as the only possible central widget.

Also I've noticed that window state is kept in the global cache using a key which contains the file name. That seems to me unnecessary. Both global and local cache use the same code under the hood, but the local one mangles the keys using file name. So, it would be simpler if the layout was stored in the c.db['windowState'] instead of g.app.db[f'windowState:{c.fileName()}']

Vitalije

[Edward K. Ream]

On Tue, Sep 15, 2020 at 9:45 AM vitalije <vita...@gmail.com> wrote:

Docks can be floated, which might be useful when using multiple monitors. Perhaps this is dock's major advantage. Docks are also necessary for the pyzo_in_leo plugin, but I would be willing to abandon that plugin.

It is possible to have outline, body and tabs in separate top level windows in no-docks. Just right click on the split line and choose "openWindow" then any widget you want and it will be displayed in the separate top level window that can be moved to the different monitor.

I had forgotten this.

So it looks like the only reason to have docks is to support the pyzo_in_leo plugin.  As the author of that plugin, I don't think this is sufficient reason to retain Qt docks.

Does anyone disagree?

Edward

[vitalije]

I didn't use this feature to have widgets in the separate top level window. Perhaps it should be improved a bit to be really useful. For example, when switching between Leo documents, these top level windows should also switch their content. Right now, they don't switch and it is possible to have displayed outline from one document while editing another document. When you extract a widget in separate window in one document, all other documents still have that widget inside the main window.

It seems that nested_splitter just needs a bit of polishing.

Vitalije

[Thomas Passin]

I wouldn't disagree, but then I haven't used the plugin.  If we drop having docks and use vitalije's suggestion, I notice that the new windows don't have a title (except for "Leo unnamed Window").  Perhaps it wouldn't be too hard to put the same name on the new window as was shown on the "Open Window" menu.

[Edward K. Ream]

On Tue, Sep 15, 2020 at 10:17 AM vitalije <vita...@gmail.com> wrote:

I didn't use this feature to have widgets in the separate top level window.

I'm lost. What feature are you talking about?

Edward

[Edward K. Ream]

On Tue, Sep 15, 2020 at 10:22 AM Thomas Passin <tbp1...@gmail.com> wrote:

I wouldn't disagree, but then I haven't used the plugin. 

At present, the plugin is little more than a proof of concept for integrating Leo and pyzo. I don't think this plugin has a future.

If we drop having docks and use vitalije's suggestion, I notice that the new windows don't have a title (except for "Leo unnamed Window"). 

The title is actually <branch-name>:untitled, or leo:untitled.

Perhaps it wouldn't be too hard to put the same name on the new window as was shown on the "Open Window" menu.

I don't understand this. What name do you propose?

Edward

[vitalije]

I'm lost. What feature are you talking about?

Sorry, I don't express myself clearly. The feature of nested_splitter which allows opening separate top level windows for outline, body and other Leo widgets. (Right click on the splitter and choosing a command in the "Open window" sub-menu)

Vitalije

[Edward K. Ream]

On Tuesday, September 15, 2020 at 10:55:57 AM UTC-5, vitalije wrote:

I'm lost. What feature are you talking about?

Sorry, I don't express myself clearly. The feature of nested_splitter which allows opening separate top level windows for outline, body and other Leo widgets. (Right click on the splitter and choosing a command in the "Open window" sub-menu)

Thanks for the clarification. This brings up an interesting design topic.

Iirc, using "global" qt docks was supposed to switch the contents of per-commander panes such as the log window and the to-do window. But I suspect that never happened.

Right now, each outline (.leo file) contains local version of the log pane, find pane, to-do pane and all other panes. That is, when you switch outlines (.leo file) all other panes change as well. Imo, this is a reasonable design, and I've never heard anyone be confused by it or complain about it. In any case, this is a separate question entirely from eliminating Qt docks.

Edward

[Thomas Passin]

If I open the "Nav" pane from the splitter bar, the window should have the title "Nav".  If I open the Spell pane in a separate window, it should have the title "Spell".  Right now each of those windows is titled "Leo unnamed window".

[Edward K. Ream]

On Tue, Sep 15, 2020 at 12:08 PM Thomas Passin <tbp1...@gmail.com> wrote:

> If I open the "Nav" pane from the splitter bar, the window should have the title "Nav".  If I open the Spell pane in a separate window, it should have the title "Spell".  Right now each of those windows is titled "Leo unnamed window".

Thanks for the clarification. #1671 suggests this improvement.

Edward

[Viktor Ransmayr]

Hello Vitalije,

Am Di., 15. Sept. 2020 um 16:45 Uhr schrieb vitalije <vita...@gmail.com>:

Docks can be floated, which might be useful when using multiple monitors. Perhaps this is dock's major advantage. Docks are also necessary for the pyzo_in_leo plugin, but I would be willing to abandon that plugin.

It is possible to have outline, body and tabs in separate top level windows in no-docks. Just right click on the split line and choose "openWindow" then any widget you want and it will be displayed in the separate top level window that can be moved to the different monitor.

Being able to move the "Render" pane to a different monitor is/ was the only reason for me to use docks!

I was not aware of this feature either. - Thanks for sharing this information.

With kind regards,

Viktor

[lewis]

The only time I use docks is to have upon launch, a vr3 rendered pane, on the RHS of body pane. I have similar frustrations with retaining a stable layout so no complaints from me if docks is dropped.

I can simply use vr3 and vr3-toggle commands.

Regards

lewis

[Thomas Passin]

When I do not use docks, VR3 always opens for me to the right of the body pane (which is to the left of the outline).  It's true that VR3 may not be visible when an outline opens, but I have linked vr3-toggle to <ALT-0>, so it's easy to make it visible.

(From time to time I have been getting an error message and VR3 will not close - only with legacy layout.  I'll try to track this down

[Later] Aha, I accidentally was running Leo 6.2.1 Final instead of the current devel version of VR3 and Leo.  I'm not seeing the bug with the latter).