Discuss: drop support for Qt docks?

[Edward K. Ream]

There has been discussion of this in the thread "The docks3 branch is ready for testing".

Given the potential impact on Leo's users, I think it wise to continue the discussion in its own thread.

Summary of previous discussions

Nobody is happy with Leo's support for Qt docks. The supposed benefits of using docks don't exist because of severe problems in creating usable layouts. Furthermore, Leo's legacy gui is actually quite flexible.

Support for Qt docks is required for the pyzo_in_leo plugin. However, this plugin is merely a proof of concept. I have no further plans for the plugin. Furthermore, Félix's leoInteg plugin supersedes the pyzo_in_leo plugin.

My opinion

Right now I would like to remove support for Qt docks. We all agree that Leo is already too complex. Removing Qt docks would make Leo simpler, not just for newbies, but for everyone. Leo's code would also become simpler. There is little risk involved because old code will move to the attic.

I would like to hear your opinions on this topic.

Edward

[vitalije]

I agree that removing support for docks will reduce complexity, and that is desirable. Personally I haven't used docks, so I won't be missing them. Perhaps users who really use this feature should raise their voices now.

Vitalije

[Thomas Passin]

I have given docks a try several times, though I have not had a need for anything they can do.  Legacy works well for me, and I would not miss docks if they were to go away.

[lewis]

I only use docks for vr3 panes and would not miss the docks features. The vr3 commands are quite sufficient.

Lewis

[Edward K. Ream]

On Tuesday, September 15, 2020 at 10:59:04 AM UTC-5, Edward K. Ream wrote:

Right now I would like to remove support for Qt docks. We all agree that Leo is already too complex...

I would like to hear your opinions on this topic.

Thanks for all your replies. The "no-docks" branch removes all of Leo's dock-related code. It was a straightforward exercise.  I won't merge this branch into devel until October 11, at the earliest. Please test the no-docks branch and report any problems.

Links: #1672: Remove support for Qt docks, and the corresponding PR1673.

Edward

[Edward K. Ream]

On Wednesday, September 16, 2020 at 6:51:44 AM UTC-5, Edward K. Ream wrote:

> I won't merge this branch into devel until October 11, at the earliest.

I am considering merging the no-docks branch into devel this coming Friday. This will improve testing.

There is little risk: `git checkout 96f2826` is always available to get the old code.

Does anyone have any problems with this plan?

Edward

[lewis]

Running no-docks branch

Leo Log Window
Leo 6.3-devel, no-docks branch, build 8cf7707903
2020-09-16 09:30:06 -0500
Python 3.8.5, PyQt version 5.15.1
Windows 10 AMD64 (build 10.0.18362) SP0

When I right click on the split-line > openWindow> Viewrendered3
The floating window launches but content area is blank, and I get this error:

hook failed: select2, <bound method ViewRenderedController3.update of <leo.plugins.viewrendered3.ViewRenderedController3 object at 0x00000223D06ECE50>>, <no module>
Traceback (most recent call last):

  File "N:\git\leo-editor\leo\core\leoPlugins.py", line 322, in callTagHandler
result = handler(tag, keywords)

  File "N:\git\leo-editor\leo\plugins\viewrendered3.py", line 1495, in update
dock = pc.leo_dock or pc

AttributeError: 'ViewRenderedController3' object has no attribute 'leo_dock'

Lewis

[Edward K. Ream]

On Wed, Sep 16, 2020 at 6:51 PM lewis <lewi...@operamail.com> wrote:

When I right click on the split-line > openWindow> Viewrendered3

The floating window launches but content area is blank, and I get this error:

...

AttributeError: 'ViewRenderedController3' object has no attribute 'leo_dock'

Thanks for your testing. I'll fix this immediately.

Edward

[Edward K. Ream]

The no-docks branch fixes this.

I have also merged the "splitter" branch into no-docks. The splitter branch attempts fixes for: #1671 and #1678. Surprisingly, both fixes involved new methods in the VR/VR3 "provider" classes. I made no substantial changes to free_layout.py or nested_splitter.py.

At least one problem remains. After creating a stand-alone VR or VR3 window, closing the that window doesn't really work, because reopening the window creates an unstyled window. One "solution" would be to disallow closes entirely, in NestedSplitterTopLevel.closeEvent.

Terry, do you have any comments? I suspect this problem is ancient, but I could be mistaken.

Edward

[tbp1...@gmail.com]

" reopening the window creates an unstyled window".  I don't see that happening.  Closing a free-floating VR3 window with vr3-toggle  doesn't work, that's true, but I can close the window by clicking in its close box.  Next time I toggle it into visibility, it opens correctly in the embedded pane as normal.

[Edward K. Ream]

On Thu, Sep 17, 2020 at 9:07 AM tbp1...@gmail.com <tbp1...@gmail.com> wrote:

" reopening the window creates an unstyled window".  I don't see that happening.  Closing a free-floating VR3 window with vr3-toggle  doesn't work, that's true, but I can close the window by clicking in its close box.  Next time I toggle it into visibility, it opens correctly in the embedded pane as normal.

Thanks for this. I closed the VR3 window by clicking the close box.

On Windows, when I reopen the VR3 window is appears again as a free-standing window, without styling.

Edward

[Edward K. Ream]

On Thursday, September 17, 2020 at 9:56:34 AM UTC-5, Edward K. Ream wrote:

> On Windows, when I reopen the VR3 window is appears again as a free-standing window, without styling.

The VR3 window looks fine if I reopen it with the Easter Egg interface. It's not styled if I use vr3-show or vr3-toggle.

Edward

[tbp1...@gmail.com]

Hmm, that's different from what I'm getting.  And what do you mean by "styled"?

Leo 6.3-devel, no-docks branch, build 00ec3fff9e
2020-09-16 09:23:46 -0400
Python 3.8.2, PyQt version 5.15.1

Windows 10 AMD64 (build 10.0.18362) SP0

[Edward K. Ream]

On Thu, Sep 17, 2020 at 10:57 AM tbp1...@gmail.com <tbp1...@gmail.com> wrote:

Hmm, that's different from what I'm getting.  And what do you mean by "styled"?

The new window is white, not black, so I assume no stylesheet is being applied.

Edward

[tbp1...@gmail.com]

That's right, I don't apply a stylesheet that would make it black.  I did try that many versions ago, when I was using a dark theme, but it wasn't fully satisfactory and anyway I'm not using a dark theme these days.

[Edward K. Ream]

On Thu, Sep 17, 2020 at 8:33 PM tbp1...@gmail.com <tbp1...@gmail.com> wrote:

That's right, I don't apply a stylesheet that would make it black.  I did try that many versions ago, when I was using a dark theme, but it wasn't fully satisfactory and anyway I'm not using a dark theme these days.

Ok. I'll take a look myself.

Edward

[Edward K. Ream]

On Wed, Sep 16, 2020 at 6:51 PM lewis <lewi...@operamail.com> wrote:

Running no-docks branch

Leo Log Window
Leo 6.3-devel, no-docks branch, build 8cf7707903
2020-09-16 09:30:06 -0500
Python 3.8.5, PyQt version 5.15.1
Windows 10 AMD64 (build 10.0.18362) SP0

When I right click on the split-line > openWindow> Viewrendered3
The floating window launches but content area is blank, and I get this error:

This has been fixed in the no-docks branch.

Edward

[Thomas Passin]

Just for historical interest and for your entertainment (since we've dropped docks) -

"... offers a more deterministic dock placement API (in Qt it is very difficult to programatically generate complex dock arrangements)"

- from an example of pyqtgraph's dock widget system.

[Edward K. Ream]

On Thu, Oct 22, 2020 at 9:35 PM Thomas Passin <tbp1...@gmail.com> wrote:

> ...in Qt it is very difficult to programmatically generate complex dock arrangements

Yup. I think Leo is better off without docks, because there are fewer choices for Leonistas to make. And less code for Leo's devs to worry about.

Edward