> > 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 instances - 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 classes. 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 sure. Vitalije -- 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.
