On Tue, Apr 15, 2008 at 8:38 AM, derwisch < [EMAIL PROTECTED]> wrote:
> > I hope there are more "important" (by any metric) users of Leo than > myself. No, there aren't :-) > > 1. Perhaps most importantly, in the unified-node world, are Leo > > outlines a proper representation of a DAG? If so, what is the > graph-theoretical correspondence between the graph and Leo nodes? > > My take on it is as follows: > > The current implementation represents a vertex- and edge-labelled > DAG. Unified nodes lose the possibility to label edges. Interesting. Before reading this I came up with a general solution that seems to relate to this idea directly. Suppose we make the vnode-tnode relationship explicit as follows. Consider an *organizer node*, the analog of the vnode, containing a child node, which may be cloned or not. Like this: - vnode (organizer node, aka node A) tnode (contained node, aka node B) To simulate cloning the organizer node in the *old* world, we create a new node, say node A-prime, clone node B and move the clone to be a child of node A-prime. We get: - vnode A - tnode B (clone) - vnode A-prime - tnode B (clone) Now here is today's aha. To make this work, **we simply hide B**. That is, we set a "hidden" attribute in tnode B, so Leo's draw code never shows it. What we see on the screen is: - vnode A - vnode A-prime but the *contents* of A and A-prime are the same. BTW, my first thought was to hide the organizer node, but that leads instantly to complications when we try to move the tnode. So the Aha could be stated: *hide the tnode*. This is pleasing because indeed tnodes *are* hidden in the old world. Naturally, it will be easy to augment Leo's tree-drawing code to support "bits" such as hide-this-node, hide-this-node's-children, etc. I suspect most of the requests [for joined nodes] stem from misplaced > analogies about object inheritance or parameterised macros. > I agree. I never paid much attention to them :-) However, we might want to provide support for joined headlines and/or body text. Joined subtrees are never going to happen, and now we can see why: it is possible to simulate such things using unified nodes. But linked headlines and body text allow a complete simulation of what your application looked like previously. Clone marks Now is the time to mention another piece of the puzzle. In order to set the clone mark, (unified) nodes must contain another ivar. Provocatively, let us call this ivar n.vUa. (It will probably be called something like n.cloneInfo). vUa will contain zero or more dictionaries. We add a dict to vUa when creating or cloning a node, and delete a dict when deleting a node. A node n is cloned iff len(n.vUa) > 1. Leo's file-read code will place entries in n.vUa when encountering a <v> element. If the <v> element has an unknownAttributes attribute, the the corresponding dict is added to the created node's vUa list. Otherwise, an empty dict will be added. This solves several problems at once: it honors the old file format, and it causes clone marks to be set correctly by the read code. Imo, we are now very close to being able to solve all problems surrounding the (old) v.unknownAttributes data. 1. The file read code will preserve v.unknownAttributes data. Of course, application/plugin code will have to determine which element of n.vUa to use, based on context, but Johannes's code already must do that. There will be a hook to allow user code to choose (again based on context) what element of n.vUa will be deleted when deleting a node, again, based on context. 2. Hidden child (t)nodes will allow Leo to simulate the old vnode/tnode relationship directly, and joined headlines and/or body text will complete the "simulation". Application/plugin code (called by drawing events) could even simulate the clone mark if desired. Conclusions It appears possible to transform an old-world Leo outline into an equivalent new-world Leo outline in such a way that a) the outlines appear identical to the user and b) the data content of the outlines are isomorphic: with *explicit* vnode/tnode relationships modeling the former implicit vnode/tnode relationships. Furthermore, the inventions needed to model vnode/tnode relationships explicitly will have other uses. n.vUa is a natural way to associate context-dependent data with a *single* node. Naturally, application code must find ways of doing this, presumably by looking up the tree for application-defined context nodes. This kind of context search is *so* much simpler than position-based approached because positions change when nodes move. Moving to the unified-node world will require real changes to Johannes's actual outline structure. But that is simply inevitable. Unless I am mistaken, however, the changes can be done automatically by revising the read code in Johannes's application. Being able to model vnode/tnode relationships explicitly is another big advantage to the unified-node world. The unified-node world is one of the most import Aha's in Leo's history. We simply must make it work. Edward --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
