Discuss: don't use Qt docks by default?

[Edward K. Ream]

Imo, reverting to Leo's legacy operation (not using Qt docks) would simplify life for newcomers.

This would entail adding a new command-line arguments, say --use-docks. Those who now do use Qt docks would have to use this new argument.

The --no-docks command-line argument would remain, so those who don't use Qt docks would not have to change anything.

Your comments, please.

Edward

[Thomas Passin]

I have mixed feelings.  I liked the old way, and I have an @button setting that switches the split view to put the body pane on the right as I prefer.  OTOH, VR3 doesn't currently work with --no-docks, and I'd just as soon not have to try to track that down and fix it!

If the old way becomes the new default, I think the way to split and rearrange the panes needs to be documented clearly in some place that a newcomer will be able to find easily.  When I started, I didn't understand what any of the menu items under Window/Window Layout meant (for that matter, I still don't understand most of them).

If Leo goes this route. I'd like to see the default layout have the body pane on the right and the tabs pane on the left under the outline pane.  I strongly prefer it that way because I think it's important to be able to see more of the body text at once. (At least up to some number of lines, like maybe 70).  I want the tabs pane on the left because if it were in a new column (say in the middle) that would crowd the body pane too much and tend to not leave enough width for it. Over the years, working with other programs and web pages, I've come to think that more than two columns in a page causes more visual clutter than I like.

Actually, even if --no-docks does not become the default, I'd still like the body-right layout to be the standard one.

[Yaakov Belch]

Regarding body-right vs. body-down: 

If Leo goes this route. I'd like to see the default layout have the body pane on the right and the tabs pane on the left under the outline pane.  I strongly prefer it that way because I think it's important to be able to see more of the body text at once. (At least up to some number of lines, like maybe 70). ...

Actually, even if --no-docks does not become the default, I'd still like the body-right layout to be the standard one.

Maybe the layout change should be discussed in a separate discussion thread.

I see the value of both layouts for different use cases.  For my workflow, body-down is better and I would not like to lose it.

[Edward K. Ream]

On Tue, Feb 25, 2020 at 12:22 PM Yaakov Belch <yaakov...@gmail.com> wrote:

Regarding body-right vs. body-down: 

If Leo goes this route. I'd like to see the default layout have the body pane on the right and the tabs pane on the left under the outline pane.  I strongly prefer it that way because I think it's important to be able to see more of the body text at once. (At least up to some number of lines, like maybe 70). ...

Actually, even if --no-docks does not become the default, I'd still like the body-right layout to be the standard one.

Maybe the layout change should be discussed in a separate discussion thread.

When using --no-docks, users can choose the layout using @string initial-split-orientation = horizontal.

We typically don't argue about preferences, but here we are in the gray area of discussing what the default value of a setting should be. Still, I don't think this is worth a separate thread.

Otoh, default command-line arguments are a bit more consequential, so I wanted to discuss it.

Edward

[Thomas Passin]

On Tuesday, February 25, 2020 at 2:44:43 PM UTC-5, Edward K. Ream wrote:

When using --no-docks, users can choose the layout using @string initial-split-orientation = horizontal.

We have got to get a handle on documentation so that things like this surface more easily.  If I install a new editor, I expect it to open up in a usable way.  If I think I would like to change something, I usually have a fighting chance by using the help and menus.   Leo is different.  Where do I go to find out about the command line options?  Well, yes, --help, if I'm a person who knows about that convention.

Oh, this isn't a command line option.  Hmm.  Now where do I go for that? How do I change font size or face?  Hmm, there are a few menu entries but not in the place I would expect options or settings. Maybe I come to realize that I should copy sections from LeoSetings.leo to MyLeoSettings.leo.  But which ones?

Well, I'm sure a lot of us know these problems.  But you know what?  I've still got font settings on my myLeoSettings.leo file that I think are obsolete, but I can't be sure which ones they are so I just leave them in.  So now I can't tell anyone else what settings to use because I don't know which ones are effective any more.

Well, sorry for the rant, it's *really* off topic.  Another thread, I suppose.

And after using Leo on and off for a decade, I still didn't know about @string initial-split-orientation = horizontal.

[Matt Wilkie]

No-docks as default is the safest route to a better experience for most people in my opinion. It's just too easy to get things messed up when using docks and getting back to reasonable restart place is very hacky.

I suppose it's too complicated to be able to switch dock modes via a menu item or command, right? What about swapping between and resetting layouts? It seems like a small thing, closing Leo and restarting is straightforward, but it really adds a lot of mental friction.

Long term, is there any viable or even a possibly-viable path to harmonizing or joining the layout methods? I'm sure the work of keeping both up to date and working indefinitely into the future is an undesirable burden.

On defaults: I also vote for 2 column layout with Outline and Log on left with Body on right using full top to bottom extent. Of course people should be able to design and save their own local default.

I don't have a recommendation for Find and Nav tabs. I frequently want them, but they're also almost always in the way. I guess that's why other editors use pop-ups. (Notepad++ replace dialog goes transparent when it loses focus, which is rather nice. I imagine that was a fair bit of work.) 

-matt

[Edward K. Ream]

On Tue, Feb 25, 2020 at 4:57 PM Thomas Passin <tbp1...@gmail.com> wrote:

If I install a new editor, I expect it to open up in a usable way. 

Leo does open in a usable way.

Oh, this isn't a command line option.  Hmm.  Now where do I go for that?

leoSettings.leo.  In general, if a setting isn't in leoSettings.leo it can safely be removed from myLeoSettings.leo

At present a few settings in leoSettings.leo are out of date. These relate to the black and beautify commands. Otherwise leoSettings.leo should be a reliable reference.

leoSettings.leo contains a check-settings script. This is mostly for my use, and it has a few problems, as described in #1511. I'll be working on this issue today. It will soon report settings in myLeoSettings.leo that do not correspond to any code. That would make the script more generally useful.

In short, the situation isn't nearly as bad as you imply.

Edward

[Edward K. Ream]

On Tue, Feb 25, 2020 at 6:15 PM Matt Wilkie <map...@gmail.com> wrote:

No-docks as default is the safest route to a better experience for most people in my opinion. It's just too easy to get things messed up when using docks and getting back to reasonable restart place is very hacky.

I agree. Let people experiment with qt docks after they have a bit more experience.

I suppose it's too complicated to be able to switch dock modes via a menu item or command, right? What about swapping between and resetting layouts? It seems like a small thing, closing Leo and restarting is straightforward, but it really adds a lot of mental friction.

I'm not going to touch the present docking code, except for fixing real bugs, like #1506 and #1507.  The code is already way too difficult.

Long term, is there any viable or even a possibly-viable path to harmonizing or joining the layout methods? I'm sure the work of keeping both up to date and working indefinitely into the future is an undesirable burden.

No. I know of no way to do that. They are two very different worlds. Abandon all hope :-)

On defaults: I also vote for 2 column layout with Outline and Log on left with Body on right using full top to bottom extent. Of course people should be able to design and save their own local default.

This seems to be the consensus. It's on the list.

I don't have a recommendation for Find and Nav tabs. I frequently want them, but they're also almost always in the way. I guess that's why other editors use pop-ups. (Notepad++ replace dialog goes transparent when it loses focus, which is rather nice. I imagine that was a fair bit of work.)

Pyzo uses a popup, as does scite. As a workaround, I recommend setting @bool minibuffer-find-mode = True.

Edward

[Edward K. Ream]

On Wednesday, February 26, 2020 at 6:53:14 AM UTC-6, Edward K. Ream wrote:

> leoSettings.leo contains a check-settings script. This is mostly for my use, and it has a few problems, as described in #1511.

Rev 3f81df in devel improves the check-settings script in several ways. In particular, it now reports when myLeoSettings.leo contains a setting not found in leoSettings.leo. There were quite a few dead settings in my own myLeoSettings.leo.

#1511 isn't quite complete yet. There are a few rough edges, which I am investigating.

I recommend not deleting dead settings unless you are sure you'll never need them. Just move them out of the @settings tree.

Edward

[Matt Wilkie]

Rev 3f81df in devel improves the check-settings script in several ways. In particular, it now reports when myLeoSettings.leo contains a setting not found in leoSettings.leo. There were quite a few dead settings in my own myLeoSettings.leo.

This script is the same as "leoSettings.leo#Startup-->Local buttons-->@button check-settings" ?

Pressing it has no effect for me (Leo 6.2-b1-devel, devel branch, build 911bb47b33).

This script/button is probably better placed in myLeoSettings than LeoSettings by default. Many will rarely see and use it otherwise.

-matt

[Edward K. Ream]

On Thu, Feb 27, 2020 at 2:41 PM Matt Wilkie wrote:

> This script is the same as "leoSettings.leo#Startup-->Local buttons-->@button check-settings" ?

Yes.

Pressing it has no effect for me (Leo 6.2-b1-devel, devel branch, build 911bb47b33).

The output goes to the console.

This script/button is probably better placed in myLeoSettings than LeoSettings by default. Many will rarely see and use it otherwise.

The function c_help.createMyLeoSettings creates myLeoSettings.leo. At present, it just creates the @settings tree, and a readme node. I suppose it could add more, but I'm not keen to do that.

Edward

[Matt Wilkie]

> This script is the same as "leoSettings.leo#Startup-->Local buttons-->@button check-settings" ?

Yes.

Pressing it has no effect for me (Leo 6.2-b1-devel, devel branch, build 911bb47b33).

The output goes to the console.

Ahhh, of course. Thanks!