> > Do you envision distributing the leoSettings.leo derived database with leo > itself? Or do you have something else in mind? I was wondering how that > first database of settings would be available at the time of leo first use. >
Leo defaults contained in leoSettings.leo should be distributed in their "pre-compiled" form. For example it could be one python module containing one big tuple of tuples representing the initial content of db. On start if this db doesn't contain table settings, table will be created and populated with the default values from this python module. This action is executed only once and it takes negligible time. For new users the result would be exactly the same as if they installed Leo and run it for the first time before they created myLeoSettings.leo. For users that have already created myLeoSettings.leo, we can allow some grace time period when Leo starts as usual (reading all settings files), and after start Leo can just store all processed and collected settings in the settings db. On the next run Leo would use db. Then in the next phase when all users have their settings db created, we can start cleaning the startup code and remove unnecessary code parts. That should cover most of the users. Users who install only release editions, will have in the next release both startup routes (one reading leo settings files, and one using settings db). On the first run the old startup route will read and collect all settings and after startup those settings are written to settings db. On every next run when settings db is present, Leo will use the second route. In the next release first route can be removed. For users who use git version, the situation will be similar only they would sooner get their settings db created. Almost none of the Leo users would have to do anything special to switch to new settings code. The only case when some action is required from users is if they switch from the current release to the release when startup code has been cleaned and Leo will miss their myLeoSettings.leo. But in this case they would simply solve the issue by opening their myLeoSettings.leo and saving it. Otherwise, as I'm conceiving of it, this scheme would then also need a > mechanism to compare the saved state with the settings .leo files, > Theoretically speaking yes. But in the reality g.app.db is never changed outside Leo (or at least we can say it is not supposed to be changed outside Leo). If someone changes g.app.db outside Leo, well I don't think that Leo developers should be concerned at all. If someone deletes g.app.db (sometimes it is suggested to do so), user should afterwards open myLeoSettings.leo and save it again, and db will be fully recreated. The worse possible case that can happen is that on the next run Leo use only default settings ignoring myLeoSettings.leo, and in this case user just need to open myLeoSettings.leo and save it. 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 leo-editor+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/348984f1-9e84-4367-950d-5fb594526eb3%40googlegroups.com.
