On Thursday, July 6, 2017 at 10:58:29 AM UTC-3, Terry Brown wrote:
> I think you're right in that another option would be to use something > like the leosax module that reads Leo outlines into a simple dict/list > representation in a fraction of the time Leo usually takes to load an > outline. Settings could be made available early by reading Leo XML > with that. > > You'd still have to re-scan them later in init. to handle @buttons and > @scripts, which need the GUI in place so they can act on it. But > that's true of any system. > > Cheers -Terry > Exactly! Whatever storage format you use for the outline, you will have to make a "second scan" of the settings when the GUI has already (nearly) loaded. With Sqlite you will also have to. Well, in fact I think that you can just make a proper caching strategy with some kind of dependency tree so you don't really need a second scan of the original settings file (or files), just a post-processing of the already loaded nodes or subtrees of the original settings files when you know you can process them. That's what I meant with the "lazy evaluation" idea, but it can be made in many ways. -- 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.
