IMHO the real problem is the way Leo handles settings at the moment. I have suggested several times in the past to change this.
The way I see it is this. Leo handles settings using the very same functionality that is used to handle its primary data - outlines. One might think it was a clever idea that saved some coding. But if we honestly and without prejudices, look at the result of this idea, we can see that it caused numerous complications in several other parts of Leo. Initialization code is an excellent example. But there is much more examples. One of the most extreme I can remember is that there is a call to c.endEditing very early before any gui element has any chance of being created. By the way this call is spread throughout the code base, contaminating and entangling all Leo's modules. I am not very convinced that it is still necessary because there had been many changes since it was introduced. It would be good to look how to eliminate the need for this call. But this should go to another topic. Let's continue with the way Leo handles settings. Let's first split this idea in two parts: 1. editing settings as an ordinary outline 2. loading settings from the outline The two parts are not necessarily bound to one another. They can be changed separately without too much trouble. While I am not very interested in changing the first, the second one IMHO should be changed in order to simplify other parts of Leo, and I am pretty sure the simplifications would be significant. If we ask users both newbies and seasoned are they satisfied with the way Leo handles settings, I guess we would find many more unsatisfied users than the satisfied ones. I remember loosing many hours on more than one occasion while trying to solve some settings issue. I am afraid of touching any settings because of these bad memories. Many things are impossible or prohibited because of this. There is no way user can load and unload plugins without restart. Python is dynamic language and there should be no problem to allow this. In almost all other editors plugins are downloaded from the internet, installed and switched on and off with the single click. Leo users can't possibly dream about such a feature mainly because of the way Leo handles its settings. Switching the theme is impossible without restart. *What can we do about it?* After editing settings in the myLeoSettings.leo or any other settings outline, user should invoke a command to save settings. This command can be executed automatically on each save. This command would read settings from the outline and build settings dict as it is now done during the startup code. The result set of settings can be stored in g.app.db for the next run. During the startup settings can be retrieved from the g.app.db in one line. This would require the least changes in Leo's code. However there might be even a better scheme. Store each setting in the db table with the following columns: (name, level, filename, type, value) where primary key is (name, level, filename). Then c.config.get<type> can be changed to execute simple query from the database selecting the value at the highest level for this outline. Leo's defaults defined in leoSettings.leo should have level=0, myLeoSettings.leo - level=1 and all other outlines should have level=2. I remember an experiment to test whether accessing settings from db would slow down Leo and result was that sqlite3 database would outperform Leo's present config machinery. Now, adjusting any setting would be as easy as executing a simple SQL command. Calling afterwards c.reloadSettings should apply new setting value immediately without any trouble. There will be no problems related to what is read before and what is read after because already compiled set of settings will be present from the early start. And if a user wishes to change some setting it can be done at any moment, and the result of this change will be preserved for the next run too. *Summary* IMHO your idea of having global settings is not bad at all. The only thing I would change is not keeping it in an .ini file, but instead in the sqlite3 database, so we get parsing, querying, persistence for free. This idea conflicts with the way Leo handles settings now. To resolve the conflict, you should change the way Leo handles settings now and it would simplify many parts of Leo's code base. Vitalije PS: I would gladly help with the necessary changes. On Saturday, August 24, 2019 at 1:50:12 PM UTC+2, Edward K. Ream wrote: > > I've just killed #1298 > <https://github.com/leo-editor/leo-editor/issues/1298> and #1301 > <https://github.com/leo-editor/leo-editor/issues/1301>. #1298 suggests > using a .ini file. #1301 suggests replacing @string theme-name with an > *implicit* setting in g.app.db. > > Both were my ideas. Both are truly wretched. Each would complicate how > Leo handles settings. Each would confuse newbies and seasoned Leonistas > alike. > > Yes, there are problems with theme files. Alas, we have to live with > those problems. Yes, theme-related settings are inconsistent. Alas, there > are reasons for those inconsistencies. Even if we could remove some > inconsistencies, doing so would imply changing all existing theme files. > I'm not going to do this to the authors of Leo's themes. > > Yes, it would be better if theme files could load before > myLeoSettings.leo. But there is no good way to do that, and the present > way does not, in fact, cause significant problems. Changing the order in > which Leo loads theme files might (will!) cause new headaches for all > Leonistas. It's not going to happen. > > 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 view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/ac2d82b5-0dd7-44c1-b652-907194a685a4%40googlegroups.com.
