Please read and discuss: Always use docks?

[Edward K. Ream]

Yesterday Leo's new docking interface saw first light.  It's in the "dock" branch. You can take a look by setting --dock in the command line. I am eating my own dog food without serious problems.  There are two bugs that must be fixed.

This post discusses whether Leo's legacy gui (look and feel) has any long-term future. This is a thinking out loud post, and I definitely want your opinions.

Important: I have no plans to do anything drastic any time soon.  I may replace --dock by --no-dock, to make docking the default, but Leo's legacy gui will continue work exactly as before for quite a while.  If I do retire Leo's legacy gui, it will likely be done in Leo 6.1, not 6.0, unless we all, unanimously, fall in love with docks.

Important: it will be much easier to follow along if you actually play with the new gui before reading on.

The new gui

The Outline dock is the central widget.  The outline dock can't be deleted, moved or floated, which is no real restriction at all. See below. The Log dock resides in the left dock area; the Body dock resides in the bottom dock area. This means that the Body dock gets the full width of the main window.

Important: The user can change the default placement of the Log and Body docs (in relation to the Outline doc) by dragging the docks.  Leo will save and restore any changes, so the defaults above don't really matter.  (Saving/restoring doesn't work perfectly at present.  That's one of the bugs that must be fixed.)

I am in the midst of re-doing the add-editor command.  It will likely use Qt's splitDockWidget method to do the gui work.  This promises to be a big visual improvement over Leo's legacy add-editor command.

The central widget

Qt does not require a central that main windows have a central widget, despite what obsolete docs may say.  However, there are two big advantages to having a central widget:

- It's not possible to have an empty Leo main window, as in the last screen shot in Chris George's recent post.

- A central widget allows the user to drag dock widgets to any area at any time.  Without a central widget you can only drag a widget to an area that already contains a dock.  Once an area becomes empty it can't be used!

At present I am leaning towards making central widget be a dock widget that can't be moved, floated or deleted.  This makes the central widget look like a dock (with the Outline label).  I think this visual uniformity is good, but it does obscure the fact that the Outline is a central widget.  I'll be experimenting further with this.

Bugs

Two bugs must be fixed.  These are early days, so there are likely more:

1. Leo doesn't preserve the sizes of the main window properly. This is likely due to interactions with legacy code.

2. Alt-x doesn't set focus properly when the body pane is free-floating.

Retire Leo's legacy look?

This question appears to violate our rule that we never discuss preferences. But imo the question deserves thorough discussion. Imo, a dock-based gui is simply better:

1. Docks are (generally) more intuitive and flexible than Leo's legacy gui.

However, this is debatable.  I await your opinions. There are some (very minor) drawbacks:

- Without packing the Tabs dock into the Outline dock, there is (I think) no way of exactly matching Leo's previous layout (@bool big-outline-pane = False).

- Without packing the Body dock into the Outline dock, there is (I think) no way of putting the body pane precisely below the Outline dock.

Imo, neither of these is a big deal.  But we shall see.

Note: Docks are required for #1093, but I won't let the tail wag the dog by letting this have any influence in our discussions.

Commands

Several commands could be eliminated if we retire the old gui, including toggle-split-direction. Docks also suggest new commands. It would be convenient to delete the old commands and add the new commands into Leo's @menu setting, but we could easily live with both the old and new commands.  Non-functional commands would simply print a message and do nothing.

Summary

Retiring Leo's legacy look and feel would be a major milestone.  I won't do it if there are serious objections to it.

Having said that, I do think that retiring legacy gui would be in the long term best interests of Leo's community:

- Unity: It would avoid splitting users into separate camps.

- Simplicity: it would simplify the code and would allow Leo to retire commands related to the old gui.

If serious objections do arise, Leo will support the --no-docks option indefinitely.

All comments, questions and concerns welcome.  Let me know if I have forgotten anything.

Edward

[Terry Brown]

I think a having a docking interface and the NestedSplitter (Easter-egg splitter right click) interface is kind of redundant, they both do similar things with similar goals and having them co-exist long term probably doesn't make sense.

Vocab: Leo's log-pane is so called for historical reasons, it's a tab-pane containing log, spell, find, and other widgets, so I'll call it the tab-pane. 

The NestedSplitter interface lets you freely arrange all widgets (body, tree, log, spell, find, todo, quick-nav, graph, tags, anything else put in the tab-pane).

Until the dock interface lets you do that, you'd lose functionality removing NestedSplitter.  Allowing free arrangement of all widgets with docks is what I attempted to do, dock interface wise, but gave up.

Basically I think the dock ui needs to let you arrange all widgets, not just the big three (tree / body / tab-pane).  Currently I think what it's added over the NestedSplitter interface is more intuitive arrangement (mouse dragging! ;-) and different aesthetics. On aesthetics, if it doesn't already have one, the dock ui probably needs a toggle for display of the dock titles, seeing long term labeling the tree the tree etc. is a waste of screen space.

You said

> - A central widget allows the user to drag dock widgets to any area at any time.  Without a central widget you can only drag a widget to an area that already contains a dock.  Once an area becomes empty it can't be used!

but I never found using only one area to be a constraint - all possible arrangements were still possible.  My approach explicitly used only one area, and you can't pull the last dock out of a nest of docks, so there was never an empty window issue.

Hopefully this new approach (using docking for just the big-three widgets initially) will allow an incremental implementation of a full dock UI, maybe first adding support for todo / graph / tags / quick-nav / back-links etc. etc., then finally breaking the log, spell and find widgets out of the tab-pane, which was the can of worms I ran away from.

Cheers -Terry

On Fri, May 24, 2019 at 10:10 AM Edward K. Ream <edre...@gmail.com> wrote:

Yesterday Leo's new docking interface saw first light.  It's in the "dock" branch. You can take a look by setting --dock in the command line. I am eating my own dog food without serious problems.  There are two bugs that must be fixed.

This post discusses whether Leo's legacy gui (look and feel) has any long-term future. This is a thinking out loud post, and I definitely want your opinions.

Important: I have no plans to do anything drastic any time soon.  I may replace --dock by --no-dock, to make docking the default, but Leo's legacy gui will continue work exactly as before for quite a while.  If I do retire Leo's legacy gui, it will likely be done in Leo 6.1, not 6.0, unless we all, unanimously, fall in love with docks.

Important: it will be much easier to follow along if you actually play with the new gui before reading on.

The new gui

The Outline dock is the central widget.  The outline dock can't be deleted, moved or floated, which is no real restriction at all. See below. The Log dock resides in the left dock area; the Body dock resides in the bottom dock area. This means that the Body dock gets the full width of the main window.

Important: The user can change the default placement of the Log and Body docs (in relation to the Outline doc) by dragging the docks.  Leo will save and restore any changes, so the defaults above don't really matter.  (Saving/restoring doesn't work perfect at present.  That's one of the bugs that must be fixed.)

--
You received this message because you are subscribed to the Google Groups "leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+...@googlegroups.com.
To post to this group, send email to leo-e...@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.
To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/8b025114-883b-404d-8b9d-c3040965df72%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Edward K. Ream]

On Fri, May 24, 2019 at 11:18 AM Terry Brown <terry...@gmail.com> wrote:

I think a having a docking interface and the NestedSplitter (Easter-egg splitter right click) interface is kind of redundant, they both do similar things with similar goals and having them co-exist long term probably doesn't make sense.

Thanks for these comments.  They nudge me towards using only the new gui.

Basically I think the dock ui needs to let you arrange all widgets, not just the big three (tree / body / tab-pane).

Yes.  Any dock widget can be rearranged.  This will be important when adding pyzo tools/docks.

It looks like the central widget isn't a real dock, so you can't, say, add a tab to it by dragging the Body dock over the Outline dock.  It's a minor annoyance, but the benefits of having a central widget are significant, imo.

> - A central widget allows the user to drag dock widgets to any area at any time.  Without a central widget you can only drag a widget to an area that already contains a dock.  Once an area becomes empty it can't be used!

but I never found using only one area to be a constraint - all possible arrangements were still possible.  My approach explicitly used only one area, and you can't pull the last dock out of a nest of docks, so there was never an empty window issue.

Chris George already as indicated that he wants to undock/float all his widgets. My experiments show that having a central widget will reduce significant confusion.

Hopefully this new approach (using docking for just the big-three widgets initially) will allow an incremental implementation of a full dock UI, maybe first adding support for todo / graph / tags / quick-nav / back-links etc. etc., then finally breaking the log, spell and find widgets out of the tab-pane, which was the can of worms I ran away from.

Yes, it's possible.  It would require mods to the plugins you mention.  For now, putting all the plugins in the Tabs dock is good enough.  I won't even think about removing the nested splitter code until the "breakout" happens.

Again, thanks for these comments.  I'm glad to hear you mostly agree with the plans.

Edward

[Terry Brown]

On Fri, May 24, 2019 at 12:45 PM Edward K. Ream <edre...@gmail.com> wrote:

On Fri, May 24, 2019 at 11:18 AM Terry Brown <terry...@gmail.com> wrote:

> - A central widget allows the user to drag dock widgets to any area at any time.  Without a central widget you can only drag a widget to an area that already contains a dock.  Once an area becomes empty it can't be used!

but I never found using only one area to be a constraint - all possible arrangements were still possible.  My approach explicitly used only one area, and you can't pull the last dock out of a nest of docks, so there was never an empty window issue.

Chris George already as indicated that he wants to undock/float all his widgets. My experiments show that having a central widget will reduce significant confusion.

I spent a lot of time on this, so I'm fairly confident a central widget is not needed and not helpful.  For Chris, you start with three docked widgets, in the same dock area, mimicking the vanilla Leo layout.  Just drag two of them out, separately, and you have all your widgets undocked (3 top level windows).  You can drag any one of them back into a docked relationship with any other.  If one of them was a central widget, you wouldn't be able to freely re-dock between arbitrary pairs of windows, and it would be really confusing.

Cheers -Terry

[Chris George]

What I am after, more than anything, is to unlink a dock widget from
the main dock. ie. currently there is only one entry in my OS window
manager so I can't "Keep Above", "Move", "Minimize" etc.

Barring that, can the functionality be replicated *within* the main
dock? I realize there would still only be one entry in the OS window
manager so manipulating those dock widgets via the OS would be out but
it would give me most of the functionality.


Chris

> --
> You received this message because you are subscribed to the Google Groups "leo-editor" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+...@googlegroups.com.
> To post to this group, send email to leo-e...@googlegroups.com.
> Visit this group at https://groups.google.com/group/leo-editor.

> To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/CAFPg46R12xh%3D4y4ywDxuQO-z468MRhV%2BdpP7ZLgq%2BEujFucNHg%40mail.gmail.com.

[Edward K. Ream]

On Fri, May 24, 2019 at 1:12 PM Chris George <techn...@gmail.com> wrote:

What I am after, more than anything, is to unlink a dock widget from
the main dock.

You can drag any dock widget away from the main window except the central widget.

Imo, there is no need to drag the central widget away from the main window. Why bother with an empty main window? In effect, the main window becomes an extension of the central widget. 

Have you tried the latest code? This is one of those times when being in the same office would help.

Edward

[Chris George]

Yes. I am using the latest.

Here is what I have so far for "workable" for me. A restriction is that the "Outline" pane is always on top when not minimized to the bottom.

When I double click the title bar on the "Outline" widget it kind of minimizes to the bottom of the screen which is usable for me but not particularly aesthetic.

.

Unfortunately, I cannot drop the "Outline" widget into one of the others with it minimizing (instead of going full screen) and none of them will drop into the "Outline" widget or I would just give all three a full-screen view and cycle between them as needed using the Body, Tabs, Outline selector at the bottom of the nested screen. I guess that that is an undesirable consequence of making the "Outline" widget into the central widget.

I use Leo in two different contexts: one on my laptop and the above would be my go-to given the existing constraints, and one on my desktop with higher resolution and an extra screen. I used to stretch Leo across both screens and have the body right in front of me and the tree and log pane on the second screen. It would be nice to have full OS control because I use the "Keep Above" all the time and all that screen real estate could be put to good use. I also will use desktop session occasionally and it would be handy to be able to treat a running instance of Leo as a server and have the widgets associated with a file available on a secondary desktop. For the laptop use case having the "Outline" widget behave the same as the other two would be ideal.

Would it make sense to enable some of these ideas using optional settings?

I am finding it challenging to enable my default arrangement. This shot is using the legacy UI. I will keep fiddling.

Chris

--

You received this message because you are subscribed to the Google Groups "leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+...@googlegroups.com.
To post to this group, send email to leo-e...@googlegroups.com.
Visit this group at https://groups.google.com/group/leo-editor.

To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/CAMF8tS2Z0ZT4Vc4rjL_wEEXJp%2BsiCkmTBJkM1S4WznURUuhA-Q%40mail.gmail.com.

[lewis]

Trying to use the leo dock branch and enjoy the new features :)

However dock branch is not cooperating.

$ git checkout dock
error: pathspec 'dock' did not match any file(s) known to git

I only get the pathspec message for the dock branch. I can easily switch to other branches.

Output of git branch does not show dock in the list.
$ git branch
  devel
  doc-updates
  fast-draw4
  fast-read
* master
  skeleton

Suggestions welcome...

Update - all fixed :) Used git fetch command to get information about new branches. I have the dock branch now.

Thanks

Lewis

[lewis]

My test scenario: 2 files opened; workbook.leo and Test_A.leo
When you click onto another Leo file/Tab, the other Tabs pane / Body pane should disappear. But they stay visible, making it confusing to use. I found myself searching in another files Tab Pane.

Example - If I edit and close workbook.leo (X on the Tab) the file saves, menu Tab disappears, but the Tabs pane and Body pane stay visible. So you have one leo file open but 4 panes visible. Only 2 of them are active.

There is no identification on the body pane heading so you can't associate it with a leo file.

You can edit this 'inactive' body pane, but you will not be asked to save if you exit fully.

In it's current form I found the dock feature difficult to use.

Regards

Lewis

[Edward K. Ream]

On Friday, May 24, 2019 at 10:10:53 AM UTC-5, Edward K. Ream wrote:

> Leo doesn't preserve the sizes of the main window properly.

Fixed at 8119f8.

Edward

[Edward K. Ream]

On Fri, May 24, 2019 at 3:45 PM Chris George <techn...@gmail.com> wrote:

> Would it make sense to enable some of these ideas using optional settings?

Yes. Per-commander settings are available at the time Leo creates the main window.

Rev 7c976f allows the central widget (the outline pane) to be moveable.  Let's let everybody play with it and see what happens.

Let me know if you think other settings would be good.

Edward

[Chris George]

Leo 6.0-devel, dock branch, build 92e392e433

2019-05-27 09:21:03 -0500

Python 3.6.7, PyQt version 5.12.0

linux

Currently unusable with more than one Leo file open.

1. Open Leo with only one file open. The file I used has a tab layout that I like for it and was saved from a previous session.

2. Open another file or try to open a new file.

3. All I can see are the tabs from the original file. If I hit the diamond in the title bar of the original tabs I can send them off to the orignal file and see the new tabs. This breaks their positioning until I go to the original file and click the diamond again.

It is very disconcerting to open a file and have the UI not update at all.

A suggestion. It might be a good idea to create a tab browser but it would only work if the name of the tab is tied to the file it belongs to and displayed to the user via the title bar. The tab browser could become a new "log widget".

Is it possible, given such a browser, to have the tabs truly minimize?

Chris

[Edward K. Ream]

On Mon, May 27, 2019 at 11:11 AM Chris George <techn...@gmail.com> wrote:

Currently unusable with more than one Leo file open.

There may be some transition problems, but I am using with two files open typically on Windows. Just checked on Linux.  All seems well.

The code is in constant flux.  If problems arise, the first thing to do is clear the caches in ~/.leo/db.

Also, you may want to update your style sheets.  See examples at the end of #1150.

HTH

Edward

[Chris George]

I already updated the style sheet locally. I will upload my changes.

Clearing the cache worked.

Thanks.

Chris

> --
> You received this message because you are subscribed to the Google Groups "leo-editor" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+...@googlegroups.com.
> To post to this group, send email to leo-e...@googlegroups.com.
> Visit this group at https://groups.google.com/group/leo-editor.

> To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/CAMF8tS1bHYD1m4O-Unkte40g2fzEHc1QLqpPwkd0f245-nbjvw%40mail.gmail.com.

[Edward K. Ream]

On Mon, May 27, 2019 at 1:23 PM Chris George <techn...@gmail.com> wrote:

I already updated the style sheet locally. I will upload my changes.

Clearing the cache worked.

Thanks for the confirmation.  And thanks for testing the new code.

Edward

[Chris George]

Correction: Clearing the cache works once. Then the same behaviour manifests and I must close Leo, clear the cache, open Leo and proceed.

It is fairly robust until I float tabs, move them around, and save one of the files. Then when I switch files it all goes to pieces again with 6 tabs floating around.

So to test:

1. Open Leo with one file.

2. Open another file. Tabs everywhere.

3. Close one file. Close Leo.

4. Delete cache.

5. Open Leo with one file.

6. Open another file. Expected behaviour occurs.

7. Switch back and forth between files. All is well with the correct tabs displaying and the other files tabs disappearing.

8. Float some tabs and arrange them in one file. Ctrl-s to save.

9. Switch files using the UI. Tabs everywhere.

This is consistantly reproducible.

This image is what I have come up with as workable for me. It gives me the three primary tabs (with spell, find, log etc.in one). I can easily switch to the tree, the log or the body using mouse/shortcuts. The two "minimized" tabs are visible and easily accessible.

But Leo won't save this configuration no matter what I do. When I reopen Leo the body and log tabs are right where I left them but the Outline tab insists on maxizing itself across the workspace and is in the docked state. ie. It is not floating. Fixing entails floating the tab and resizing it to where I put it in the first place exery time I open the file. I tested this with several files and it is consistant.

The ideal for me would be to be able to float all tabs and then drop them all into the outline tab and use the tabbed interface at the bottom to switch between tabs that are maximized into the workspace.

Chris