ENB: re singleton docks

[Edward K. Ream]

This post contains a few notes in my Engineering Notebook.  Feel free to ignore.

Rationale

#1289: Singleton docks, is a precondition for using pyzo's features in Leo.  Imo, #1289 is worthwhile all by itself. Leo's legacy operation is a bit strange.

Status

All work is being done in the "gui" branch.

qt_gui.__init__  now contains the following:

if g.new_gui:
    self.main_window = self.make_main_window()
    self.make_all_docks()
    self.create_menu_bar()
    self.create_mini_buffer()
    self.create_status_bar()
else:
    self.frameFactory = qt_frame.TabbedFrameFactory()

Legacy methods have camelCase names; new methods have underscore_style names.  This naming convention is pragmatic and useful, despite being "inconsistent".

The code above looks simple enough, but it implies significant changes:

- There is only one main window.  The legacy code puts a QMainWindow in every top-level tab.

- The main window contains an "Outlines" (plural) dock, containing a QTabWidget, one outline per tab.

The code gets called once, not every time a new outline is created.  This is what we want, but gui docks will no longer know anything about c, the present commander.  Instead, the individual tabs of the Outlines dock must be given c, using something like g.app.gui.createOutlineTab(c).  Changing outline tabs must switch c in the Log dock.

Configuration

#1289 implies substantial changes to Leo's startup configuration.  Per-commander settings are not available when creating the global docks.  It might be possible to retain Leo's present configuration scheme, which uses c.db for the first commander c that is loaded.

I am considering switching to g.app.db for sizing Leo.  That is, Leo's main window would open with the size it happened when it last closed, regardless of what outlines are being opened.  Imo, this would be more intuitive for users. This would also remove some seemingly-out-of-place configuration code from Leo's "fast read" code.

Pyzo style classes

Initially, I'll make the minimum possible changes while refactoring.  This seems prudent.

Later, I may refactor further, using what I think of as pyzo style gui classes.  These encapsulate behavior more cleanly than Leo's present gui classes.  In particular, pyzo style classes define and handle Qt signals.  Leo's legacy code has never used signals, though some recent changes do.

This kind of refactoring isn't strictly necessary to support pyzo docks, but it seems worth doing.

Summary

#1289 implies non-trivial, refactoring.  This refactoring must not affect Leo's core in any substantial way.

#1289 also implies significant changes to Leo's configuration. Imo, these will likely be simpler and more intuitive.

Leo might use pyzo-style gui classes for better support for Qt signals. I won't do this initially.

Edward

[Matt Wilkie]

I am considering switching to g.app.db for sizing Leo.  That is, Leo's main window would open with the size it happened when it last closed, regardless of what outlines are being opened.  Imo, this would be more intuitive for users. This would also remove some seemingly-out-of-place configuration code from Leo's "fast read" code.

I would like this to be the default.

I do see a strong argument for being able to save and load layouts. Activity profiles if you will. A project which is all about writing needs a very different layout from one which is all about code which is different from organizing a website with vr previews.

-matt

[Edward K. Ream]

On Tue, Aug 20, 2019 at 2:18 PM Matt Wilkie <map...@gmail.com> wrote:

I am considering switching to g.app.db for sizing Leo.  That is, Leo's main window would open with the size it happened when it last closed, regardless of what outlines are being opened.  Imo, this would be more intuitive for users. This would also remove some seemingly-out-of-place configuration code from Leo's "fast read" code.

I would like this to be the default.

Thanks for your vote.

I do see a strong argument for being able to save and load layouts. Activity profiles if you will. A project which is all about writing needs a very different layout from one which is all about code which is different from organizing a website with vr previews.

The present "sessions" machinery probably does this.  Details are hard for me to remember. There are subtle interactions in various places.  In some sense, Qt does almost too much automatically. Very little Leo code is involved.

This is one of several considerations that will require extensive testing, on the scale of the testing required for the dock-related code in Leo 6.0.

Edward