The docking code is complete, for now

See #1150 . All bugs have been fixed or deferred. There is no need to set legacy_log_dock to True. The deferred bug happens only if docks can be floated. Allowing floatable docks is not a high priority for me. The only remaining item is

QWidget.raise_ fixes cross-window focus problems

Rev 18af67e in the "dock" branch ensures that the Tabs dock is visible *while setting focus in the minibuffer.* It was far from obvious how to do this. After three hours of work, the fix was straightforward: *use QWidget.raise_ twice*, first on the Tabs dock, then on the minibuffer widget

Re: Status of docking code

On Tue, May 28, 2019 at 3:00 PM Terry Brown wrote: NestedSplitter has an open window function that allows any pane to be moved > to another window. > True, but opening another body pane has (at least) the same focus problems that floated docks have. Indeed, Alt-x doesn't work at all, and Ctrl-F

Re: Status of docking code

On Monday, May 27, 2019 at 5:55:54 PM UTC-5, Edward K. Ream wrote: > The docking code is feature complete. Full details at #1150 . But now the features have changed, hehe. Thanks to Chris and Terry for their thoughts and tests. While we

Re: Status of docking code

On Tue, May 28, 2019 at 3:01 PM Chris George wrote: When I grab the splitter with my mouse and drag it all the way either right > or left I am prevented from going to the edge of the screen. The tab > getting smaller stops with an inch or so to go. > Yes. I see this too. My intent was to be

Re: Status of docking code

On Tue, May 28, 2019 at 3:00 PM Terry Brown wrote: > The drawback is that Leo's main window must contain all the docks. > > Leo has always had this constraint, > > > Not really, NestedSplitter has an open window function that allows any > pane to be moved to another window. > > I've changed

Re: Status of docking code

When I grab the splitter with my mouse and drag it all the way either right or left I am prevented from going to the edge of the screen. The tab getting smaller stops with an inch or so to go. My intent was to be able to totally maximize the body pane by moving the splitter to the edge making

Re: Status of docking code

On Tue, 28 May 2019 14:52:58 -0500 "Edward K. Ream" wrote: > The drawback is that Leo's main window must contain all the docks. > Leo has always had this constraint, Not really, NestedSplitter has an open window function that allows any pane to be moved to another window. > but it does make

Re: Status of docking code

The first file now retains sizing. The second file still doesn't save the tab layout. Chris On Tuesday, May 28, 2019 at 12:53:11 PM UTC-7, Edward K. Ream wrote: > > On Tue, May 28, 2019 at 12:08 PM Chris George > wrote: > > So basic concept: I was floating windows to get them where I wanted

Re: Status of docking code

On Tue, May 28, 2019 at 12:38 PM Chris George wrote: > I notice that while the window location is persistent between restarts > that the sizing is not. > That's correct, because sizing is done via another route, and only when you save the file. It's on my list to explore saving window sizes in

Re: Status of docking code

On Tue, May 28, 2019 at 12:12 PM Chris George wrote: > In my screenshot above with the Outline tab on the left and the Body tab > as host for everyone else, would it be possible to have the splitter > between Outline and Body be able to move to the extreme left of the window? > This would allow

Re: Status of docking code

I notice that while the window location is persistent between restarts that the sizing is not. I opened another file. The window positioning on the first file is saved properly at the end of the session but the window positioning for the second file is not saved. The terminal message says it

Re: More dock experiments

I used Add Body Editor and all worked as expected. But you cannot place a tab into a virtual desktop session, at least on Linux. The window manager has no idea that the tab exists. Just FYI. Chris On Tue, May 28, 2019 at 9:56 AM Edward K. Ream wrote: > > Rev 140aa9f in the "dock" branch

Re: Status of docking code

In my screenshot above with the Outline tab on the left and the Body tab as host for everyone else, would it be possible to have the splitter between Outline and Body be able to move to the extreme left of the window? This would allow a true fullscreen for the Body host. Chris -- You

More dock experiments

Rev 140aa9f in the "dock" branch contains my latest. Please clear ~/.leo/db before using it, and whenever things start to go south ;-) Recent tweaks: 1. The documentation indicates that the central (Outline) widget should be a QDockWidget. This constraint reduces the number of tests I am

Re: Persistent persistence...

On Tue, May 28, 2019 at 9:37 AM Terry Brown 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

Re: Status of docking code

On Tue, May 28, 2019 at 10:16 AM Chris George wrote: > > A docked tab can have other tabs dragged by their title bars and dropped > into it creating the "tab" interface at the bottom of the host tab. A > floating tab cannot be used as a host for this purpose. Using a docked tab > as a host

Persistent persistence...

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

Re: Link for rst primer has changed

On Mon, May 27, 2019 at 2:07 PM Ross Burnett wrote: > On the *Creating Documents from Outlines* page ( > http://leoeditor.com/tutorial-rst3.html), the link for the rst primer > should now be > https://www.sphinx-doc.org/en/master/usage/restructuredtext/basics.html. > The existing link,

Re: Status of docking code

On Monday, May 27, 2019 at 5:55:54 PM UTC-5, Edward K. Ream wrote: > There are serious problems [restoring dock layouts]. Rev 7631d60 appears to fix those problems. It also uses docks whenever possible. Please report any remaining problems. I'll remove the traces after we are more sure that

Re: Status of docking code

On Mon, May 27, 2019 at 5:55 PM Edward K. Ream wrote: The *legacy_log_dock* compile-time switch in qt_frame.py is True. Imo, it > should remain that way. > On second thought, it will be better for testing to put the Find and Spell tabs into docks. It's also more consistent. Plugins can easily