>  Please tell us where we can find the latest version.
> Edward

I am glad that you find new data model still interesting and that you will 
give it a chance. Latest version is not very far from the version I have 
sent to you before. As I remember I have just fixed one small issue since. 
It caused tests to fail when gnx in the outline is not the same as the gnx 
in external file. That was a two lines fix. Since then I haven't worked on 
the model. There are lot of small things that I put on hold until after 
this weekend, that now require my attention. As soon as I can work again on 
model, I plan to work on the undo/redo functionality next. It may cause 
some changes in the model. That is why I don't think that documenting and 
explaining model have to wait a bit longer. But as soon as I am satisfied 
with the shape of model, I'll do my best to explain it in full detail. Then 
we can discuss it further.

Are you talking about screen redraws? That might be made faster by drawing 
> only the visible part of the screen. 

Yes, I had mostly drawing in mind. Drawing tree in Leo perhaps can be made 
faster using the same algorithm as in my prototype and using positions for 
traversing movements. We can say perhaps that position is a temporary index 
in database. Your comment made me think about this possibility a lot. I 
can't say exactly why I doubt that it would be very effective or point 
where potential problem will arise. Here are just a few thoughts:

   - it is not enough to have a sequence of visible items. We also need to 
   link visible items with the positions. In the prototype this is achieved by 
   using the fact that positions are immutable which is not true for p 
   - traversing tree using p instances involves list manipulations and 
   instantiations which are more expensive than integer arithmetic that is 
   used in the prototype
   - in new model it is well defined where is the next visible node 
   relative to the current one. In case of v instances it is hard if not 
   impossible to figure out what will be the next visible v node

Anyway, these are only my guesses. Maybe some experimenting will show more 
precisely what is missing and whether it can be easily added to the p and v 

I remember that I have tried few months ago in 768-new-tree branch to make 
some improvements in tree drawing, but with no real success. At that time I 
have already implemented drawing tree in leo-el-vue and leo-cljs using very 
similar algorithms as the one in the prototype. Yet, I haven't found the 
way to apply the same algorithm using p and v. There may be a way, I am not 


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.

Reply via email to