On Dec 15, 9:51 am, "Edward K. Ream" <[email protected]> wrote:
As I think more about this, I think some of the problems can go away.
> 1. Some reasonable concept of top-level nodes must be defined.
It's reasonable to define a top-level node as any node that has no
parent. This might cause some surprises as top-level nodes magically
disappear when a an "in-link" is created.
Clones *are* well defined with no change to the data model: every
*tnode* already has a vnodeList ivar that is a list of all vnodes that
share that tnode. All such vnodes are clones of each other.
> We want the top-level nodes to "cover" the outline
Happens automatically, with the definition above.
> 2. Iterators become more complex, less useful and less intuitive in
> general graphs. This has the potential to be hugely confusing, as
> well as difficult or impossible to implement.
I'm not quite as sure of this as I was. Terry's idea of having the
drawing code expand a node at most once implies a tree-drawing
iterator that would be well defined.
An all-nodes iterator would be similar. This probably would not be
too confusing, provided one didn't care much about node order.
Parents and sibling iterators would be pretty much unchanged.
Anyway, with these conventions, it becomes easy to "project" an
arbitrary graph onto a representation as a Leo outline. Nodes without
parents are the top-level nodes. A node's children are the nodes in
its child list, *regardless* of whether the node has already been seen
in the tree-drawing traversal. The only difference is that tree-
drawing code expands a node only once.
What we must (and can) avoid is having child nodes appear and
disappear depending on whether that node has already been seen in the
tree-drawing traversal.
In short, we could represent an arbitrary graph as a tree, without too
much fuss. The question remains, however, whether such a scheme would
be particularly useful. As before, back links would essentially be
hidden. It still seems to me that using a separate graph widget to
represent nodes outside of Leo's present data framework is the
simplest, most intuitive way.
Edward
P.S. There is no doubt at all that Leo's file format would have to
change to support general graphs. Not difficult, but a compatibility
problem.
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
-~----------~----~----~----~------~----~------~--~---
