On Mon, Jun 26, 2017 at 12:09 PM, Terry Brown <[email protected]> wrote:
> On Mon, 26 Jun 2017 09:21:46 -0700 (PDT) > vitalije <[email protected]> wrote: > > > As I have mention in other thread I have some ideas about how can be > > improved Leo code that deals with the configuration and user settings. > > Very interesting analysis. I've had similar experiences in the init. > code, that is, for example, why the QDock interface to replace > free_layout is kind of stalled. > I'll be happy to help you init your QDock code :-) I'm actually pretty happy with Leo's init code. The complexity could be said to arise from the "has a" pattern of object relationships rather than the "is a" pattern. That is, all (or almost all) of Leo's objects *contain* other objects. They do not *inherit *other object classes. This was a conscious choice, and I have never regretted it, no matter what the problems. The alternative is endless worries that ivars of one class conflict with ivars of other classes. Python's _ and __ conventions do not perfectly solve the problem. In cases where Leo classes are subclasses of non-Leo classes, Leo uniformly (I think) uses the "leo_" prefix to ensure that Leonine ivars do not conflict with ivars of the base class. Seems like you've proved a SQLite based config. store is possible, and > the idea of having an editor for that outside of Leo is interesting - > it wouldn't be hard to code a PyQt editor but using a web front end as > you suggest would work in PyQt free environments - with the lynx > browser it could even work in a console only setting. > I think a key/value cache is conceivable. But it must merge seamlessly with Leo as it is now. I'm not going to allow massive changes to Leo's startup code, or abandon myLeoSettings.leo and leoSettings.leo. There is no chance of changing my mind about this. On the other hand it must also be true that Python and Leo are up to the > task of managing config. - the current system works, it's only > drawbacks are the init. complexity you've mentioned. And the > difficulty people have in changing settings. > These difficulties arise either from bugs (fairly easy to fix) or from the inherent complexities of individual settings. > What you have maybe not covered (yet) is outline specific settings. I > think an external settings store could manage these by mapping some > outline identity to DB content. Imo, caching myLeoSettings.leo and leoSettings.leo is enough. > And also that managing settings in Leo allows hierarchical management, > which has advantages. > These advantages must remain. We will see what Edward thinks, but the opportunity to toss a lot of > c.config init. complexity might be tempting. > Init complexity is inherent, as is read complexity. This is not ever going to change. Caching might improve performance, but it will *increase*, not decrease code complexity. The general principle is straightforward. Simple user interfaces may imply lots of complexity behind the scenes. MacOS code is hugely more complex than DOS code. Edward -- 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.
