On Tue, Sep 8, 2020 at 12:02 AM Mike Hodson <[email protected]> wrote:
At least to me, generic dock UX should be something like this: > Thank you for your comments. We both agree that docks should "just work", but what that means requires consideration of many hidden details. > You have docks. > They can move. > The layout of docks can only change the layout if --init-docks is true. This prevents unintended layout changes. Alas, it's not always possible to undo changes to Qt dock via the UX. In particular, moving the VR pane out of the body pane can't be undone. If you mistakenly do that, the only remedy is to start over again with --init-docks. Within a specific layout, you can change the size of docks by moving dividers. For floating docks, you can move them anywhere on the screen. They should instantly save in the current open leo file as how they are > when moved. > Leo does save all layouts, either when the .leo file closes, or when Leo closes, whichever comes first. You can see this in action with --trace=dock > In generic apps the dock layout should save to the config and reload upon > app relaunch, but Leo is very outline-specific in how things work, so we > keep the dock tied to the outline. > There is an option to set what Qt calls the "central widget". By default this is the outline pane. They should be reloaded from the leo file when opened. > That is what happens. I am trying to simplify the behind-the-scenes details. > There should be some gui options, menu item, something, "Save current dock > state as default". "Reset docks to Leo default". > This has been requested several times. Imo, it would be better to use the layout of the first loaded .leo file as the default for new files. I am presently struggling with what happens when the first specified .leo file does not exist. There is already a mechanism for using a hand-created layout as a very last resort, but just now there are problems. > Perhaps there could be a "load dock state from saved" that would modify > the current dock state to that of a different Leo file without opening the > Leo file as a working edit. > This is possible, I think. However, I would prefer to simplify matters, not add yet more complications. > Enable and Disable toggles should be visible in the GUI and not > commandline options because they are graphical elements of the program. > Something that is implicitly graphical to modify should also be graphical > to enable, save, etc. > --use-docks must be a command-line option because it affects the early stages of Leo's startup code. By the time any Leo outline becomes visible it is too late to change anything. I am presently deep into testing and experimentation. The goal is to eliminate duplicate code and reduce the number of paths through the code. It's worth a lot of work to make things as simple and easy-to-use as possible. Edward -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/CAMF8tS3X%2BDnq7%3Dm4vMjm571ODLyEg5i7Vawnp%3DCi5PUUnrwSBw%40mail.gmail.com.
