On Thu, Jun 29, 2017 at 3:25 PM, vitalije <[email protected]> wrote:
> 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. > One of my "hidden" purposes in leading the Leo project is to encourage people to push back when I misunderstand or appear to reject a proposal. I do this by changing my mind a lot :-) [my experiment] > > 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. > True, I am hesitant to approve any sweeping new idea, but I am not particularly fond of Leo's xml format. Furthermore, Leo already supports .leo.zip formats, and there have been proposals (not rejected) for using json or yaml for Leo's outlines. > [sqlite] > is meant to replace a humble open (file) function. > Well, this certainly changes my point of view. If > [large software projects] 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. > This gets my attention. > 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. > And just when I was getting comfortable with git branches. .. 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. > Yes. It has to be a powerful as gitk. > > 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. > Excellent. I was pretty sure that settings were not the real issue. > > The only thing currently missing is restoring the position and dimension > of the application window on screen. > It will be trivial to implement though. > Heh. Last night I realized that that was something that would have had to be handled as a special by the reload-leo command. 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. > It's easy. Load unitTest.leo, select the "Active Unit Tests" top-level node, then do Alt-4 (run-selected-unit-tests-locally) Run the tests *before *making your changes. Per #512: unit tests are failing for Terry <https://github.com/leo-editor/leo-editor/issues/512> some tests may fail on your machine. Make a note of those failures. You can safely ignore those failures *after *making your changes. If everything goes well I would publish git branch with my code so that you > can review it. > Excellent. I will be very interested in the what you have done. > 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. > You can experiment with the beautify commands. The @nobeautify directive will preserve formatting in special cases, such as code containing tables. But formatting is not that important. pep 8 is a guide, not a straitjacket. 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. > .leo.db files would coexist alongside .leo and .leo.zip and possibly .leo.json files. > 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. > That was Joe Orr. Hopefully, this time I have better explained the reasons and ideas that I > had in mind. > Indeed you have. If I left something unclear please help me by asking questions and I would > try to answer as concise as possible. > Your intentions seem quite clear. Furthermore, replacing git is a completely separate matter from replacing .leo files, so we can don't have to change our git work flows just yet ;-) Great work. What I like most about our (all the Leo devs) collaboration is that after everyone has pushed back against initial ideas we end up with something better than any one person would have created on their own. 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 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.
