On Sun, 16 Jul 2017 07:58:06 -0700 (PDT) "Edward K. Ream" <[email protected]> wrote:
> On Sunday, July 9, 2017 at 2:15:06 AM UTC-5, Edward K. Ream wrote: > > > >> On Wed, Jul 5, 2017 at 3:51 PM, Terry Brown > >> <[email protected]> wrote: > >> > >>> 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. > >> > >> It does seem that a more orderly, official and documented startup > >> process would be beneficial in many ways. > > > I keep coming back to this idea. Keeping details deliberately vague, > the startup process might be something like: :-) I think there's an intuitive sense that there might be some potential for simplification, which would be very valuable. When you think about the components and how they relate, it doesn't seem like there needs to be so much forward declaration and split initialization. Although it's entirely reasonable that such situations arise through code evolution - adding tabs to the log pane is I think a good example. There was a critical point where it could have conceptually been "add the log widget to the tab pane" rather than "add tabs to the log pane", but at that point the implications were much less obvious than they are now. So my thought with this non-code based run-level / init. steps listing is that it will either show opportunities for simplification, or illustrate clearly why some entangling is unavoidable. Must admit I'm currently looking at it much more from GUI startup for the QDocks branch than basic outline loading, but I think the same process applies in both cases. > 1. Init the most basic vars, and do the most basic imports. > 2. For each loaded file, init *all* of Leo's settings, using sqlite > and maybe a new "minimal" Commands class to read settings files when > necessary. 3. Everything else. That is, create a commander for each > to-be-loaded file, init the commander thoroughly, and create the > outline from sqlite or the actual external file. > > This is pure speculation. I may be relying on sqlite for too much > magic. Hope not. > > As more magic, it would super if we could get rid of caching > entirely... As hinted in my other post re "yes to all", I can't help feeling that caching is getting a bad rap, assuming it's working reasonably. I think it's being blamed for things it shouldn't be causing, unless it and / or reload have unidentified flaws. And my recollection is that it causes a massive decrease in load time of outlines with many external files. I guess that at least is easy to test. 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.
