> > > I do not understand why you are concerned about settings. This seems > like a natural migration path: > > I am not so much concerned with the settings as I am concerned with Leo's init code. I have a strong feeling that the way Leo handles settings at present complicates init code. Surely, it has some beauty in the idea that settings can be represented the same way as document outlines are and that the same code that reads document can be used to read settings as well. There is something self similar, something fractal-ish in that approach. However, it makes init code complicated more than it must be. There is also great flexibility in the way user can adjust settings. But all that flexibility and beauty vanishes in a moment when user wants to do simple thing, to set shortcut or change font or color of something. I believe that just a few of Leo users can and do appreciate that kind of beauty because most of them never bother themselves to read Leo's source. However, it may be that many more users are being annoyed by the complexity and amount of work that is required to change one simple keystroke or color or font. Who knows how many potential users have tried Leo and gave up too quickly considering themselves as not enough clever or skillful to use Leo. Yes, we know that no question and no problem reported to this forum stays unanswered longer than a day or two. But we can't be sure how many users never dared to post a question.
> - When in "sqlite mode", saving an outline will create x.leo.db. This > includes settings files. Similarly, reading an outline will read x.leo.db. > > - Retain Leo's startup logic, completely unchanged. This will load > settings from leoSettings.leo.db and myLeoSettings.leo.db. > > Yes, this is already done with the code in sqlite-leo branch, and that branch can be used that way without any further implications on Leo's code. However, as I have stated in README of that branch, I am striving to make a prototype of Leo that can have much simpler init code, Leo which would allow user to change any setting and see its effect immediately, and in which user won't have to imagine what color or font would look like while entering text value for those settings. I believe that sqlite as document format has great potential and that it would be appreciated enough by users so that the old xml format can be deprecated. I certainly don't want Leo to loose anything or to be broken in anyway. I have no intentions to force any user to change his/her habits and preferences. I believe a smooth transition to sqlite format is achievable. Behind the scene Leo would make db versions of xml settings files. And maybe it can be announced that support for xml settings files will be dropped in Leo 6.0 or 8.0. Support for reading outlines in xml format need not to be dropped ever. Just reading settings from xml files. Meanwhile users can edit both versions of file formats and Leo will keep up with both versions. But on the day that Leo is allowed to ignore xml settings and can rely on settings from db only versions, much of the init code can be reduced. Heroic alternatives threaten to break Leo in subtle ways. > > I certainly would not want to do that. But without such attempts we are doomed to find local maximum only and maybe we will miss opportunity to reach much higher maximum in close neighborhood. Vitalije > -- 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.
