On Dec 17, 8:56 am, "Edward K. Ream" <[email protected]> wrote:
> p.isExpanded can no longer be a
> property of either p.v or p.v.t, but must instead be a property of the
> position p!
We don't want the tree drawing code to remember positions, so we must
use the expansion state of tree items instead of p.isExpanded.
This will only work if we draw the "entire" tree initially, and then
update incrementally. So there appear to be two choices:
1. Remember the expansion state of positions.
2. Use the clever tree drawing code, and remember the expansion state
of tree items.
My intuition says these approaches must be equivalent in some sense.
You could call this a mathematical intuition--the two points of views
must be so-called "duals" of each other. If that is so, we can expect
to be able to use helper data structures in lieu of doing the clever
tree drawing algorithm. From the opposite side of the duality,
considering how to do the clever tree-drawing algorithm might point to
the needed data structures.
In any case, it now appears that the tree drawing code, far from being
straightforward, shows where the deep problems lie. Those problems
necessarily will involve positions, iterators, and the related
position methods that traverse the tree, especially p.threadNext.
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
-~----------~----~----~----~------~----~------~--~---
