[Pharo-project] A lil simplification of MorphTreeNodeMorph

Alain Plantec alain.plantec at yahoo.com
Wed Apr 6 10:31:30 CEST 2011

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

More information about the Pharo-project mailing list