On Apr 12, 6:21 pm, "Edward K. Ream" <[EMAIL PROTECTED]> wrote:
> Drat. The same old problems with anonymous vnodes...It looks like more > invention > is needed. One possibility is to move *all* node attributes into tnodes: marks, expanded status, uA's, etc. The effect of this is to make tnodes the "real" nodes, with vnodes being only a mechanism for have the "same" node appear in different places in the outline. This is not so drastic as it might appear: vnodes are "almost" the same as tnodes now. (It's easy to lose sight of this fact). Indeed, only cloned nodes have two or more vnodes sharing the same tnode. If we deemphasize vnodes we are making clones more similar what used to be called joined nodes. By sharing expansion state, for example, we are making visually apparent that clones, like what used to be called joined nodes, are in essence the *same* node. This is an old, old debate. However, we could say that the Great Graph Aha implies that we lose nothing by identifying nodes with tnodes. The immediate payoff is that we could use tnode indices (gnx's) in .leoDB: there would never be any need to know about vnodes. Aside: the present position is represented by a series of child indices, like 0.3.4. This scheme is unaffected by this discussion. Identifying "real" nodes with tnodes would imply a change to Leo's file format. The time to make such a change is now, while I am deep into the complexities of reconstituting pasted nodes using sax. As always, the goal would be for the sax parser to read all old .leo files, and as always, older versions of Leo would not be able to read the new file format. Just some thoughts for now. Don't panic :-) Does anyone know of a situation in which having attributes attached to vnodes is essential? I don't. For example, the hidden machinery should work the same if the associated attributes are attached to <t> elements. Edward P.S. I am starting to like this idea. It eliminates, once and for all, the confusion about whether to put data in vnodes or tnodes. The answer would always be: in the tnode. That being so, it might finally be time to eliminate the <vh> elements from <v> elements. <v> elements would merely indicate outline structure: *all* the data would be in <v> elements. P.P.S. Alas, there remains a messy complication: for any node, i.e., a tnode, we know exactly what it's descendants are. However, if we think of clones as being the *same* node, we are left with the fact that "it" can have multiple parents and siblings. Drat again. The vnode code won't change, and neither will most of Leo's DOM, but the question of whether clones are one or more nodes really can not be resolved in a completely simple way... To be continued... EKR --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
