Le 06/04/2011 10:02, Igor Stasenko a écrit :
yes, positioning is not quite correct. But the idea is to use layouts
instead of morphs to
adjust positioning.
Because having 3 extra morphs per list item which sitting there only
for markup is not fun.
And it affects a rendering speed considerably.
yes, it is a workaround.
take the current implementation as a functional requirement.
MorphTreeMorph is cool because it can be used for lists, trees and tables,
but I agree, it is badly implemented.
So I fully agree with you, the positioning logic should placed be in the
layout managing
I think that MorphTreeMorph can't be efficient for very big lists
because each row may contain a lot of morphs.
Yes, but you can use morphs only for those items which are shown on
screen, while for those which outside
you don't need to use morphs at all.
The idea is that You could keep in memory all morphs which
representing the tree, but don't iterate over them
every time. Just add to submorphs only those which currently visible.
this is the idea behind LazyMorphTreeMorph, Morphs added only when they
become visible.
What could be done is to simplify things even more, so creating a list
item will be cheaper and skip many initialization,
unless it is necessary.
yes, thanks a lot Igor!
Cheers
Alain
Cheers
Alain
