The entry point I envision is this: The gui shows 3 buttons: <=, ||, =>
If the node which currently has focus, only the double bars are active, clicking that button puts the current node in the repository. if the node is edited, the double bar and the left arrow become active: clicking <= reverts the node and makes the right arrow active || puts current version into the repository rinse and repeat. The backend would be some sort of db, a versioning system would make it pretty simple. There could be any number of ways to define the node state. I don't see @auto files as exceptional, other than the gnx changing. In my workflow, an @auto node is either a - class declaration - method definition - var declaration - chunk of doc In each case, I'd like to have access to versions of the node. If this were implemented, I think experience would dictate what metatada was important/useful to store for a node. And, my interest is not in Leo files which multiple people edit at once, that's for source code, and a solved problem. I consider my Leo files a reflection of a personal proclivities in viewing data. Thanks, Kent - On Mon, Dec 26, 2011 at 10:26 AM, Seth Johnson <[email protected]> wrote: > On Mon, Dec 26, 2011 at 11:19 AM, Seth Johnson <[email protected]> > wrote: >> On Mon, Dec 26, 2011 at 7:44 AM, Edward K. Ream <[email protected]> wrote: >>> >>> I think that's ok. Leo is not going to change in any "big" way unless >>> the way forward is so simple and compelling that it will be impossible >>> to forget: like "webs are outlines in disguise." So far, nothing >>> remotely that simple has appeared. >> >> >> One very simple thing that can be done very easily would be to just >> store the Leo data as it is, with no thought of distribution or >> collaboration "within the database implementation" -- then you just >> store .leo files in the database, produce the external files as you >> currently do, and collaborate with the external files the way you do >> now. That would create a database backend that could be extended >> gradually. As long as it is done in a way that's basically "the same >> as" a .leo file, any more fundamental reengineering for distribution >> and collaboration would be no more complex than converting from the >> model of the Leo file would be in the first place. And in the >> meantime, people might bang on the backend in interesting ways while >> keeping its compatibility with the Leo app and its file format. If >> people show ways of doing distribution and collaboration that way, you >> can ponder those without worrying about impact on standard Leo. > > > Distribution and collaboration *and versioning* -- I forget! > > It might be good to start without versioning and all the state stuff, > just do without any added features, and then look at different ways to > do the versioning based on having a "classic Leo" database > implementation in place. Apparently versioning is a key rationale for > going to the database, but maybe you can move forward by just setting > a gold standard for classic Leo first. > >> Seth > > -- > You received this message because you are subscribed to the Google Groups > "leo-editor" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/leo-editor?hl=en. > -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
