> > > Thanks for the thorough explanation. But you don't need a GUI app to > read an XML, as you don't need a GUI app to read from an SQLite file. I > understand that you need to read all the settings files to be able to > fully initialize Leo, but you don't need (or should not need) al Leo's > machinery to read the settings files. Even if they are .leo files. > Clearly the part that needs to be changed is that "Leo needs all of its > power to analyze outlines with settings". It may be the case at present, > but it should not. > > I agree on that, but at present Leo relies on the same machinery for analyzing settings and reading documents. That makes things more challenging for init code.
> It should be possible to take the code which reads Leo files apart from > the rest and see if there are parts in the settings that need a delayed > evaluation (o some other kind of lazy evaluation) to succeed and decide > on them on a case by case basis. It could even be handled with a > dependency tree if needed, but it cannot be a closed loop. > > It isn't really a closed loop but one very convoluted. Machine can find way out and Leo successfully starts up, but it is very hard for human brain to follow that convoluted path and understand what is going on. I also agree that it should be possible to separate code that reads settings and code that reads outline. I'm sorry I don't have the time at this moment to take a look at the > initialization code to help further in this envdeavour, so you are in > your right to ignore my comments completely and go on with the best > solution you can achieve. But from an architectural point of view, the > need to simplify the initialization code should not imply the need to > change the form in which settings are stored. > It is not question of storing settings but collecting them that complicates init code. Right now I am working on standalone script (sax2db) which should read settings file, analyze settings in it and produce a collection of valid settings in that file, (and finally to store collection in db, but let us ignore this for a moment). I try to use as little as possible from Leo machinery that requires any kind of initialization, and to use as much as possible of Leo's code that can stand on its own without special initialization requirements. If I succeed in this maybe that code could be used even without sqlite just to make g.app.config and c.config available sooner in init phase. As you can see even if I work towards adoption of a new format for Leo documents, some results of those endeavors may be found useful even without changing format. I don't see why those settings affecting those objects can be changed and > we can see their immediate effect in real-time when they are in Sqlite and > cannot be when they are in an outline. > Maybe I didn't make myself clear. It is not my claim that it can't be done without sqlite. What I wanted to say is that using the same code for reading, analyzing, collecting settings from outlines and for reading and dealing with documents makes it impossible to simplify init code. OTOH complicated init code makes it difficult to show real-time changes and requires restart. Maybe use of sqlite for settings could have been just an excuse to introduce new separate code for settings. But in my mind idea of using sqlite as a file format have been for years, and not only in my mind but also in this forum it was mentioned 9 years ago. On the road to sqlite file format next step is dealing with settings. That is why I have started this thread. To discus about best way to deal with them. It may look like I have lost my compass and mixed several goals into one, but the truth is I am aware that these are separate issues that just happen to lie on the road that leads to my final goal. I try to deal with them one at the time. This time it is Settingsville that I have to pass through. 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.
