On Saturday, August 10, 2019 at 3:08:54 PM UTC-5, Edward K. Ream wrote: > Rev 75d917 in the pyzo branch adds icons to the pyzo_file_browser plugin, completely vindicating an incremental approach:
Last night's rev 77004da makes more of the dock functional. The plugin now contains an interim copy of pyzo's config code in zon.py. This replaces the FileBrowserConfig that I wrote previously. Not sure why FileBrowserConfig doesn't work... *Debugging and responsibility* Recall that the "big question" is how to meld pyzo's code with Leo. Recent work makes the following clear: - Gaining access to (copies of) Pyzo's code will be relatively easy. - Many changes to pyzo's code will be needed. All such changes must be debugged, and become the responsibility of Leo's devs, present and future. *Incremental packaging* Moving pyzo's config code into the plugin was just barely feasible, even for a prototype. Several renaming hacks were needed. Those hacks were justified *in the moment* because I had full control of all names in one place. The new leo/external/pyzo/pyzo_config.py contains copies of the config-related code in the plugin. However, there is now duplication between pyzo_config.py and the previous pyzo_icons_.py. Doh! I now see that putting them in the pyzo folder was a mistake. There would be no way to access them without importing pyzo (executing pyzo.__init__)! Instead, I plan to put all needed support files in a new leo/plugins/ *pyzo_support* directory. *Functions *from various places in pyzo's startup code will go into pyzo_support/*pyzo_functions.py*. *Modules *from pyzo's directory tree will go into subdirectories of pyzo_support. *Example* The top level of the plugin is now: << pyzo_file_browser imports >> iconprovider = QtWidgets.QFileIconProvider() @others # Compute standard places. pyzoDir, appDataDir = getResourceDirs() # Load all icons. pyzo_icons = loadIcons() # From pyzo.start pyzo_config = loadConfig() This does the most (all?) of the needed startup code. The getResourceDirs, loadIcons and loadConfig functions are minor mods of the "real" pyzo startup functions. They will migrate from the plugin to pyzo_support/pyzo_functions.py. The config class code in the plugin will migrate to pyzo_support/util/zon.py, without the naming hacks. *Important: *The plugin uses pyzo_config where the original code uses pyzo.config. Eventually, it would be good to monkey-patch pyzo.config, but this would require that importing pyzo/__init__.py have no side effects. I've discussed this previously, but now it's becoming more important. This means that significant changes will eventually have to be made to pyzo's startup logic. *Configuration, again* Pyzo's config code must be significantly changed. I reverted to code in zon.py because I had no clue about what the legacy code was doing. But the legacy code will not suffice. Just as a start, some pyzo options will become Leo options. The big change in attitude is that there is no such thing as a config shim. There is just configuration code, which will change as needed. *Summary* The big question is how to meld Leo and pyzo. The answer is becoming clearer. The pyzo_file_browser plugin has, somewhat unexpectedly, become an excellent test bed. Incremental changes to this plugin (and soon, support files) replace the notion of shims. The upcoming leo/plugins/pyzo_support directory tree will contain a significant amount of pyzo code, some of it modified. This directory will allow access to pyzo's code, without any side effects caused by importing pyzo itself. This pattern is an essential step in all pyzo-related projects. Many mods to pyzo's code will be required. All those mods must be debugged. All become the responsibility of Leo's devs. Work on the pyzo_file_browser plugin has been rapid, and fun. Clearly, all the puzzles that arise can be solved fairly elegantly and rapidly. The resulting techniques will be the basis of integrating other parts of pyzo into Leo. Generalizing these techniques is always in my mind. Onward! Edward P.S. I am committed that the file browser plugin will become part of Leo. I have no commitments that the other parts of pyzo become part of Leo, despite them being nominally scheduled for Leo 6.1. Having said that, I may get carried away by the puzzles involved, and do my best to move as many as I can into Leo as soon as I can. EKR -- 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 leo-editor+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/f30dae7f-2f52-4edc-9d8f-1c7dd977c3d2%40googlegroups.com.