ENB: next steps for pyzo-in-leo

[Edward K. Ream]

Recent progress has been spectacular, as documented elsewhere.  It should now be straightforward to create all of pyzo's docks in the pyzo_in_leo plugin. Making all those docks functional is another matter entirely.

This post is a "thinking out loud" entry in my Engineering notebook.  Feel free to ignore.

Configuration

The notion of a config shim was a false start. Using pyzo's actual config code in zon.py is a big step forward.  But big challenges remain.

Leo's config model is not a great fit for pyzo's. Many of Leo's config settings are read-only, accessible only via c.config.get* (getBool, getString, etc).  Leo uses c.db to read/write settings that might change while Leo is running.  In contrast, pyzo uses pyzo.config to both read and write settings.  The models must somehow be reconciled.

Handling every pyzo setting on a case by case basis is not a pleasant prospect. All changes would have to be back-ported when upgrading pyzo.

Hmm.  As I write this I see that a possible workaround would be to re-imagine zon.py so it does the necessary adjustments.  You could call this an in-place shim.  It's an idea worth exploring.  It would be much better to make all necessary changes in one place, even if zon.py becomes more complicated.  Otoh, it might end up simplifying zon.py in the end.  We shall see.

The main window

I'll have to keep an eye on the differences between Leo's and pyzo's main window. Pyzo's MainWindow class contains methods that Leo's main window lacks.

The existing pyzo.start function creates the main window using the MainWindow class, a subclass of QMainWindow.  The new pyzo.start_pyzo_in_leo function implicitly uses Leo's main window, c.frame.top, an instance of DynamicWindow.

At one point the lack of a setMainTitle method caused a crash. It doesn't seem to matter just at present. Iirc, pyzo_file_browser may have injected MainWindow.setMainTitle into Leo's actual QMainWindow, but that probably got lost in the great collapse of code.

This issue isn't nearly as troublesome as config issues.  Adding any needed methods to Leo's own main window class will be simple and good.

Menus

Adding pyzoic menus to Leo can be done in the pyzo_in_leo plugin.  This plugin will likely just use yet another copy of the pyzo code.  Yes, this code might have to change when updating pyzo, but it's unlikely that such changes will be needed.

Summary

Melding pyzo's config code with Leo's remains, by far, the most important and challenging part of the pyzo-in-leo project.

Edward

[Edward K. Ream]

On Tuesday, August 13, 2019 at 6:22:23 AM UTC-5, Edward K. Ream wrote:

> It should now be straightforward to create all of pyzo's docks in the pyzo_in_leo plugin. Making all those docks functional is another matter entirely...

> Melding pyzo's config code with Leo's remains, by far, the most important and challenging part of the pyzo-in-leo project.

Allow me to disagree with what I have just written.  Yes, config issues are big, but other issues might be even bigger. It's too soon to say.

Despite all the recent progress, I sometimes feel daunted. There are so many unknowns. The notion of "playful prototype" does help, but maybe not all that much ;-)  This is still a highly experimental project.

Edward

[Edward K. Ream]

On Tuesday, August 13, 2019 at 6:22:23 AM UTC-5, Edward K. Ream wrote:

Melding pyzo's config code with Leo's remains, by far, the most important and challenging part of the pyzo-in-leo project.

Status

1. I added a call to callLater(pyzo.shells.addShell) at the end of make_all_docks.  This revealed several problems with the init code, including some buglets (undefined pyzo ivars) in the pyzo code when using the plugin's (slightly altered) startup logic.

2. Pyzo's config code continues to be a confounding factor in understanding, initing and executing the code.  The plugin uses the real pyzo's config.ssdf file, and that makes the startup code appear to be non-deterministic.  The value of command-line arguments (sys.argv) is another confounding factor.

3. Leo does not shut down properly when the pyzo_in_leo plugin is enabled.  There is some unused code that does this.  I'll probably just have to put it back in place.  It's an easy monkey-patch to Leo itself.

Here are my next steps...

Execute pyzo's startup code exactly as pyzo does

Failure to do this may be causing subtle startup bugs, including the buglets described above.  I shall replace start_pyzo_in_leo with the following functions in the plugin:

- pyzo_start:  a copy of pyzo.start, with as few changes as possible.  It will call:

- pyzo_main_ctor: a copy of pyzo's MainWindow.__init__.py,which will call:

- pyzo_main_populate: a copy of pyzo's MainWindow._populate.

De-fang pyzo.config

This can't wait any longer.  pyzo.config is, in effect, a set of global vars that depend on the real pyzo's configuration.  It's way too confusing to continue to allow this coupling. The changed code will be an in-place shim. Traces in pyzo.config should be helpful in debugging.

Create a dock for pyzo's main "Editors" window

In the real pyzo this is the central widget, not a dock, but Leo already has a central widget :-) Making pyzo's editors visible will help with debugging, and might even remain in the final code.

Summary

I have begun debugging pyzo in the context of the pyzo_in_leo plugin.

Subtle differences in the plugin's startup logic are causing subtle, difficult-to-find, execution time errors.

pyzo.config must be made deterministic. This will start the process of melding pyzo's config system with Leo's.

For debugging (and longer?), I'll make pyzo's editors visible by putting them in a new Leo dock.

Edward