yes, it is a workaround. take the current implementation as a functional requirement.
Good point! Yes igor we want the same, simpler and faster :D
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