I'm wondering if it would be a useful thought experiment to list a series of "run levels" (https://en.wikipedia.org/wiki/Runlevel) or levels of initialization for Leo - just a textual list where we do our best to be aware of dependencies for each level.
So for example, in UI initialization, you might have: - main window exists - outline managing added (top row of tabs) - pane management system added - log added - tree added - minibuffer added - find added - spell added - a body added the idea being that nothing further up the list depends on anything further down the list. I think in the case of settings, the goal with the sqlite approach is - g exists - g.config added [now within load init. for workbook.leo] - config created (to become c.config, even though c not created yet) so config objects are created and ready to use without the need to read outlines. This is somewhat orthogonal to using sqlite as a format for outlines, although using sqlite as a format for outlines gets around the problem of two separate files for an outline and its local settings. I'm just as interested in the UI case as the settings case, getting a better handle on that would help a lot with the "view rendered 4" and Qt dock projects. So I guess a first cut would be working out the order of creations and deferments in the UI startup code. Cheers -Terry -- 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 post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
