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: 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

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

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

Status of docking code

The docking code is feature complete. Full details at #1150 . One serious bug remains. There are serious problems reloading Leo after moving docks when multiple outlines are open. The workaround is to clear everything in ~/.leo/db. *Gui