Persistent persistence...

[Terry Brown]

Just a couple of dock related thoughts.

To replace the functionality of the NestedSplitter interface the dock
layout needs to support multiple (named) persistent layouts of plugin
docks (widgets in docks, really, plugins don't need to know about
docks specifically). I used this to make Leo into things like a DB
schema editor and a graph editor and a todo / calendar manager.

I had this kind of persistence mostly working in my attempt at docks,
if that's a useful reference. Basically plugins register as widget
providers and the layout machinery works down the list of providers
asking who can provide "X" when it's restoring a layout.

I assume you're allowing all docks to be tabbed docks? So essentially
every "pane" becomes (optionally) a "tab-pane". This lets you have a
lot of widgets "on-hand" without consuming lots of screen space.

Also I'm not sure if you still have a central widget, but the that a
central widget can't be dragged into a different dock relationship or
receive incoming dragged docks(*) seems like it would be an
unnecessarily confusing asymmetry.

* I guess it could receive them for left/right/above/below, but not as
a tab sibling, so still confusing.

General thoughts but mainly just a reminder that NestedSplitter
persists plugin widget layouts.

Cheers -Terry

[Edward K. Ream]

On Tue, May 28, 2019 at 9:37 AM Terry Brown <terry...@gmail.com> wrote:

To replace the functionality of the NestedSplitter interface the dock
layout needs to support multiple (named) persistent layouts of plugin
docks (widgets in docks, really, plugins don't need to know about
docks specifically).

The present code associates layouts with the first loaded .leo file.  That is, the key in g.app.db include the full file name.  Not sure this suffices.

I assume you're allowing all docks to be tabbed docks?  So essentially
every "pane" becomes (optionally) a "tab-pane".  This lets you have a
lot of widgets "on-hand" without consuming lots of screen space.

Yes.  The central widget (Outline dock) may be a special case.

Also I'm not sure if you still have a central widget, but the that a
central widget can't be dragged into a different dock relationship or
receive incoming dragged docks(*) seems like it would be an
unnecessarily confusing asymmetry.

Afaik, not having a central widget makes it difficult to move widgets in relation to the (missing) central widget.

To repeat, it would be great if you, Chris and I could be in the same room while we experiment.

I'm working today on making everything work as smoothly as possible.  It's unexpected futzy.

Edward