In an earlier thread I said that Leo's init/load process was too complex to understand "analytically".
However, I now need to do just that. I have been studying the code intensely, using Leo's clone-fine-all command to gather the necessary data. It would be very difficult to understand all the complexities without clones. Here are some notes... ===== g.openWithFileName will handle settings without loading files twice The new_config version of g.openWithFileName will contain 5 (!) load phases:: Phase 1: Start the init process. A: Open the file **if** the file is a .leo file. B: Call app.newLeoCommanderAndFrame to *start* the init process. Phase 2: Create the outline from the .leo file. Phase 3: Update the local settings, creating c.config.settingsDict and c.config.shortcutsDict. No calls to c.config.getX should happen before this phase is complete. Phase 4: Call all finishCreate methods. Phase 5: Complete the initialization. ===== Unify complex code There should be one and *only* one version of the complex open code. Indeed, the init code is so complicated that it would be hopeless to attempt to keep different versions in sync. Happily, there is an easy way to do this: g.openWithFileName should create *all* outlines! That is, g.openWithFileName should never "fail": it will create an empty outline if no file name is given, or if the file does not exist. This is a big collapse in complexity. With this rule in place, the *only* calls to newLeoCommanderAndFrame will be from g.openWithFileName. This is another significant collapse in complexity. ===== Init discipline To make the 5-phase load process work, newLeoCommanderAndFrame must ensure that no c.config.getX method is called from any of the methods invoked from newLeoCommanderAndFrame. At present, there are few exceptions to this rule. I'll handle this by splitting several finishCreate methods into "init" and "finishCreate" parts. newLeoCommanderAndFrame will call only the "init" parts. g.openWithFileName will call the corresponding finishCreate parts in Phase 4. It will be easy to ensure that no calls to c.config.getX before Phase 4: The Commander class will contain a new ivar, say c.configInited, initially False. c.config.get will issue a warning if c.configInited is False, and the end of Phase 4 will set c.configInited. You could call this a ever-present embedded unit test. There is no guarantee that this scheme will work, but I think it will. 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.
