On Mon, 26 Jun 2017 09:21:46 -0700 (PDT) vitalije <vitali...@gmail.com> 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. 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. 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. 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. The only concern there is that that's what c.db does currently and it seems more fragile than it should be - certainly more fragile than @settings in the Leo file for a particular outline. I think it uses a hash of the filename to store values for a particular outline, but (a) that breaks with different paths that evaluate to the same thing, and (b) I think the code generates different hashes in 2 and 3, although these are things that could be fixed. I was wondering about the root node gnx, but looking at my main outline now I see tbrown.20170418151203.1 and I'm sure it's older than 2017-04-18. And also that managing settings in Leo allows hierarchical management, which has advantages. We will see what Edward thinks, but the opportunity to toss a lot of c.config init. complexity might be tempting. Cheers -Terry > Using small python script I have collected all settings from > leoSettings.leo and created a dictionary whose keys are types of > settings (int, ratio, float, string, color, bool and data) and values > are lists of setting names. > > Then I made list of all possible pairs (type, setting-name) and for > each pair I put the current value in sqlite3 database table. > > For each pair I have checked that the value returned by corresponding > c.config.get<Type>(name) method is the same one that is returned by > sql query for given settings name. > > Then I have tested using timeit module, both methods of reading > settings and the result is that using sqlite to retrieve settings > value is actually faster then using plain c.config module. Speed gain > is small, just about 12.4%, but at least experiment proved that using > sqlite for dealing with configuration is possible. > > What would be the benefits if Leo configuration code use database to > store and retrieve settings. I believe that Leo startup code could be > greatly simplified if the settings are available just by opening a > database connection. There is no need to postpone any initialization > because settings haven't been fully read yet. I have tried several > times to understand what exactly is going on during initialization > but I gave up every time because it was nightmare of indirect calls, > halfway initialization, ... Almost all important members are > initialized twice or more times. Once with the simple or dummy value, > and later reinitialized with the correct one. Because of that there > are everywhere checks if some dict is properly initialized or not. > Arguably all that stuff could be written much simpler if c.config was > present at the very beginning of the execution process. > > Attached to this message is sqlite3-config-benchmark.leo. Executing > the script in its first node, performs all the steps I wrote about > and prints in Log pane times for retrieving value of every setting > 1000 times. On my computer it take about 6.5 s for c.config and 5.5 s > for sqlite3 to give all those values. > > I am not so good in programming PyQt gui, but if all settings are > kept in sqlite database, I could easily make single page web > application and minimal REST server for accessing/adjusting all > settings in web browser. Leo would need just one simple command to > open local url in users default browser and user would be able to > tweak any and all of the settings in browser. Server could be > implemented in python and may actually run in the same Leo process or > in other separate process. Leo would be aware of any such change in > settings immediately. It would not be necessary to restart Leo to see > changes. Maybe some of the changes would require restart, but most of > them IMHO would not. 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 post to this group, send email to leo-editor@googlegroups.com. Visit this group at https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
