On Thu, Aug 9, 2018 at 7:57 AM, vitalije <vitali...@gmail.com> wrote:
> >> Great help in quickly traversing tree to the given top position is to now >>> how many nodes are in its subtree. In my model it is the size of a node. >>> >> This turns out to be more important than I first thought. If the code is to set scroll bars properly, it must compute the number of visible nodes preceding the first *actually drawn* node. Some "inlining" of the computation might be important. Expanding all nodes in a large outline is now no longer guaranteed to be fast enough. I'll look into it. I have been wondering whether "stable" positions might be added to Leo's >> existing data model. Can you point to some documentation? >> > > The fragile position parts are integer index of vnode and int indexes in > their stacks. If you add a dictionary to each node that maps child > addresses (for example letters) to child nodes then position can put that > address (letter) into its stack and its childIndex field. Accessing child > nodes then would be two step process instead of just one. First you convert > index into address (a letter) and then that address into a child node. That > is little more work, but positions would become more immune to the tree > modifications. > This looks worth doing. Please create an enhancement request. I have a vague fear that we might have to be careful about the dictionary keys. Segundo Bob sometimes uses a script to open multiple .leo files within a few milliseconds. That cause great problems with gnx's in the past, but perhaps that's not a problem in this case. Edward -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at https://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/d/optout.
