This post contains a few notes in my Engineering Notebook. Feel free to ignore.
*Rationale* #1289 <https://github.com/leo-editor/leo-editor/issues/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 a 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 -- 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/d41d70ec-73a6-4be1-9c6c-5c536a595945%40googlegroups.com.
