On Feb 17, 6:43 pm, "Edward K. Ream" <[email protected]> wrote:
> The original beautiful plan to read each local .leo file once has fallen prey > to an ugly fact :-)...The second plan will simplify code using another > strategy... Hurray! The new plan is a *spectacular* success! ===== The unification of Leo's startup code Creating Commands objects is now completely self-contained. In particular, c.__init__ now creates the fully-inited gui frame. This is a revolution in Leo's startup code! Indeed, the old code inited Leo windows in several places, and in several phases: Places: c.__init__, the end of g.app.newLeoCommanderAndFrame and the end of g.openWithFileName. Phases: g.app.newCommanderAndFrame, g.openWithFileName and c.finishCreate. The new code has c.__init__ do *all* the work, in one place, and in one phase. This will be supremely important for future maintainers. The old code was difficult for me to understand yesterday, even after a full week of study. The new code is a simple as could possibly be imagined. This is a gigantic step forward for Leo. This spectacular collapse in complexity will have all sorts of excellent consequences... ===== More cleanups A number of possibilities for cleaner code now present themselves: - c.__init__ no longer needs a frame argument, a surprisingly important conceptual simplification. - All calls to g.app.openWithFileName will be replaced by a call to Commands(...), that is, c.__init__. Because this code happens at startup, it may still be useful to wrap this in a method that imports the leo.core.leoCommands module, but this is a nit. It will now be perfectly clear that c.__init__ does all the work. - I now see that having g.openWithFileName "fail" causes needless complications. It should simply create a new Leo window if it is given no fileName argument, or if the file does not exist. This will eliminate a lot of "if" statements ;-) Note: I have already removed the switches that enabled the new code. This makes the code much easier to read. I'll be upping these simplification later today. ===== The final phases Once the code base has been cleaned, I'll turn my attention to the "new_load" and "new_config" schemes. new_load: simplifies the infamous readSettingsFiles methods into several cleaner methods. new_config: uses a much simpler per-commander c.config.get method instead of delegating to the horribly complex g.app.config.get method. There is significant coordination between these two schemes. In fact, they are really two aspects of the same problem. I'll probably merge these two switches into one. Developmental unit testing has already proven both schemes. It should be relatively straightforward to fold the new code into the new code base, but that is not guaranteed--there are still hidden complexities to be dealt with. Still, I expect the code to be fully tested in a day or three. Once all the new code is complete, it will be time to repackage all the recent work as methods of the LoadManager class. This promises to eliminate significant code duplication in the leoBridge module. We'll see about that... Finally, g.openWithFileName will do nothing but call a corresponding LoadManager method. The details of loading do not belong in leoGlobals.py! Edward -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
