>> > 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 >> > >
