On Thursday, June 29, 2017 at 4:16:38 PM UTC+2, Terry Brown wrote: > > Hey Vitalije, what are you working on exactly? Not wanting to > duplicate any effort and wondering if you're working on the sqlite > settings idea or something else, and if you have any thoughts on the > sqlite approach separating file specific settings from the file they > apply to, vs. the current system's inclusion of those settings in the > same file? > > Cheers -Terr >
I am sorry for the delayed answer. I worked last night and came to the state where I have a script that can turn any open Leo document into sqlite database with the same name except the extension (for example: LeoPyRef.leo turns into LeoPyRef.db ). I have changed the isLeoFile so that it now accepts extensions .leo, .db and zip files. I have changed openLeoOrZipFile so that it checks if it is a .db file that needs to be opened and if so it opens a sqlite connection and returns it instead of open file. Returned value from this method goes unchanged through some helper methods and finally arrives in readSaxFile. There I have simulated the parsing of xml nodes to tree of SaxNodeClass objects and switched the call to fc.parse_leo_file which returns SaxNodeClass root node with the call to retrieve the tree of SaxNodeClass nodes from database. It allowed normal start of Leo and opening LeoPyRef.db as it were ordinary LeoPyRef.leo. Later I have discovered that it would be better to intercept the normal reading procedure not in readSaxFile but higher up in call chain in method getLeoFileHelper. Because with the first variant the values stored in database were lower level so that they represent tree of SaxNodeClass nodes which would then be transformed into v-nodes. Instead it is easier to put v-nodes directly in database and then to retrieve higher level v-nodes tree and set it to c.hiddenRootNode in getLeoFileHelper. That was the end of my yesterday work. Today I couldn't touch it until now and now I am going to finish the prototype that is able to open any Leo file stored in sqlitedb and to read settings from the good old leoSettings.leo and myLeoSettings.leo files. Next I plan to make a script that would analyze all settings files and to put all settings into database table like in the previous experiment I did. The only thing missing in that experiment I believe was additional field in database table which should contain level of settings source. For example default value should be on level zero, leoSettings (if it is something different than default I am not sure) on level one, myLeoSettings on level 2 and finally settings in leo document would have level 3. Then querying database about any settings value can be performed like this: select value from settings where key=? order by level desc limit 1; Which could be explained like give me the value of given key with the highest level. The idea is that every Leo document would contain all settings defaults, leoSettings and myLeoSettings and also any additional settings for particular document. When user changes myLeoSettings settings, earlier created documents will have outdated values. In that case executing simple command would update all values inside db leo document. To summarize: 1. user can keep all present settings unchanged 2. user still can change settings in myLeoSettings.leo 3. every new created file would have those settings embedded 4. user can choose to execute simple command to update settings in any Leo db document or perhaps Leo could automatically check the modification time of myLeoSettings.leo and offer a user to update settings if they are outdated 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.
