In the other thread I have announced my experiment but it seems that I haven't explain it very well. Let me try another way.
The trouble I bumped into few days ago with changing shortcut settings was just a primer that set me in motion. My initial experiment with collecting all settings in sqlite database and speed test were intended just to make an argument. Although it started with the settings it was not only about settings. It was about new file format for Leo. I knew from earlier discussion in this forum that Edward is/was not willing to approve such ideas. This time however I decided to give it a try just for myself and it happened that this time Edward actually encouraged me to go on with the experiment. But I suspect that my idea is still not very well explained/understood. There used to be somewhere on this forum some links to the talk that Dr.Richard Hipp, the author of SQLite, gave explaining what he wish that user of SQLite library have in mind when using it. It is not meant to compete with multi-user, server based database systems. It is meant to replace a humble open (file ) function. He gave some examples of missed opportunities in some large software projects like OpenOffice that use xml as file format for their documents. If they used SQLite instead they would be able to open document almost instantaneously, implementing undo/redo that can survive restart of application would be a trivial task, and lot of other advantages he has shown. There are also several talks about the advantages of SQLite's source code control tool *fossil* over git. Not only that history (undo/redo) of one file is possible to be kept inside document file, but also the history of all project files, with all history details like check-in comments, wiki pages, branches, diffs,... all that stuff can be kept inside one file. User can copy that file on memory stick, send it via e-mail or google drive, it can be displayed online with just one executable file and it can be used for self hosting project site on the web. Something like github site packed in one executable file and one repository file. It handles user accounts, permissions, registrations, bug reports, to-dos,... almost everything that is needed for software-project hosting site. Inspired by those talks I have made a script that puts entire Leo tree in fossil repository and the other script that can recreate Leo tree from fossil repository. I remember it was very fast operation even if it used files on disk for the transfer to fossil. About as fast as is checking and parsing external files in Leo. Another script used to give a timeline list of all versions of Leo tree that are recorded in the repository. That list was printed in Log pane and it was possible for user to choose one of listed versions and Leo would recreate that particular version of tree. At that point I have abandoned the experiment because I haven't any clue how to create a GUI for all those features. It wasn't so useful with just a bunch of scripts and Log pane as the only GUI elements. I have also realized that there is a problem with the gnx-s. Two different versions of Leo tree had to be shown in different commanders because all changed nodes can not have the same gnx and different bodies or headlines. I still have a strong feeling that this idea of keeping the whole history of the tree in one file has some potential, but it needs suitable GUI to be useful at all. As I had no idea how suitable GUI could look like, nor how to solve the issue with conflicts between two different historical versions of the same node, I start to think about using sqlite database as file format for Leo documents. Knowing it would be hard to sell the idea, I let the time to pass and I did nothing about it. However that idea has never left my mind since. Recent events have lead me to final decision to do something about it. I have dived once again in Leo start-up code and this time I had more success. I have finally made the first version of my prototype. With my changes Leo can accept as input argument database file. Now I can open any ordinary xml Leo document, click a button and database version of Leo document is generated in the same folder where Leo file is located and with the extension '.db' instead of '.leo'. Later Leo can open that db file and have the same tree it would have if it parsed xml file. leoSettings and myLeoSettings as well as inside document settings are respected with the current implementation. The only thing currently missing is restoring the position and dimension of the application window on screen. It will be trivial to implement though. I haven't run tests because I am not sure how to run them. Edward, Terry please give me the proper sequence of steps how to run all tests and check if I broke something or not by my changes to the code. If everything goes well I would publish git branch with my code so that you can review it. I suppose my code style is not in accordance with the standard that is used in Leo, so I expect that I will have to prettify my code but I didn't bother to do it yet. I have mention on the other thread that I gathered some web browser client scripting skills (also fair amount of the server stuff skills). If Leo document were sqlite database I would be able to try something with the old idea of showing whole history of Leo tree but this time in web browser. I imagine that perhaps in web browser it would be easier to overcome problems with showing more historical versions of the same node. Also someone on this forum announced development of browser viewer of Leo documents. I expect that it could benefit also from sqlite file format and maybe some server stuff. I am sorry for very long post and for all mistakes I have made writing it. Hopefully, this time I have better explained the reasons and ideas that I had in mind. If I left something unclear please help me by asking questions and I would try to answer as concise as possible. 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.
