Database is just a part of fossil. It isn't question of where Leo can keep its data. It's about keeping a history of data. Fossil keeps (in efficient way) all versions of the data, it can show the diffs in several formats, ... pretty much all that git does. The advantage of using fossil instead of git, IMHO, is that:
- it doesn't need to be installed (it is just one executable file, available for all platforms that Leo supports) - it keeps all its data in just one file, while git creates .git subtree On Monday, January 16, 2017 at 5:25:22 PM UTC+1, Terry Brown wrote: > > Another question is whether the integration is just at the load/save > level or at the node traversal level, i.e. constantly using a data > backend. I think if we started with the load/save level, the sweet > spot might be some subtree / node level live refresh from a data > backend. > > For diffs, seems an xml to yaml conversion would achieve that? Like I > say, haven't been following the conversation too closely. > > Cheers -Terry > > I don't expect integration to be at node traversal level. At the load/save phase (or even on an explicit user request), fossil would record the new version of the outline. Later, a user might want to see how and when some node has changed, or what was it like in some earlier version. The simple script I made for the experiment already enables all that functionality. The next more challenging task is to create an elegant GUI that user can use to run all those functions. I haven't programed in PyQt for a long time. Many things I used to know I forgot and there seem to be a lot of changes in PyQt since. Nevertheless, I can imagine how GUI might be like. For example, imagine a small slider widget along the bottom of body, or in status line, that represents time. User can slide it left or right and the selected body would change accordingly as it was at the selected moment. When focused slider would enable user to switch to the previous/next version using the arrow keys. I am not sure that all this would be useful at all. I can't recall when was the last time that I needed something like this. But maybe I would use it more often if it was possible in the first place. The way I see it, this can be interpreted as "undo/redo" functionality but persistent between editing sessions and spread at node levels, i.e. every node has its own "undo/redo" timeline. It may be useful, who knows? 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.
