A lil simplification of MorphTreeNodeMorph

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
37 messages Options
12
Reply | Threaded
Open this post in threaded view
|

A lil simplification of MorphTreeNodeMorph

Igor Stasenko
Cut out some code and extra morphs.
It speeds up rendering to 60% of original.

@Benjamin
Please verify if it positioning stuff correctly. Because in my image
Settings are now OK.

@all
I need your feedback to know if it works correctly in other places,
where tree morph used.

--
Best regards,
Igor Stasenko AKA sig.

theTreee.2.cs (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: A lil simplification of MorphTreeNodeMorph

Stéphane Ducasse
**TX!!** :)
It was cool to see you both hacking to speed it up.

Stef


> Cut out some code and extra morphs.
> It speeds up rendering to 60% of original.
>
> @Benjamin
> Please verify if it positioning stuff correctly. Because in my image
> Settings are now OK.
>
> @all
> I need your feedback to know if it works correctly in other places,
> where tree morph used.
>
> --
> Best regards,
> Igor Stasenko AKA sig.
> <theTreee.2.cs>


Reply | Threaded
Open this post in threaded view
|

Re: A lil simplification of MorphTreeNodeMorph

Alain Plantec-3
In reply to this post by Igor Stasenko
Le 05/04/2011 20:08, Igor Stasenko a écrit :
> Cut out some code and extra morphs.
> It speeds up rendering to 60% of original.
cool
thanks for reviewing this code!
> @Benjamin
> Please verify if it positioning stuff correctly. Because in my image
> Settings are now OK.
>
> @all
> I need your feedback to know if it works correctly in other places,
> where tree morph used.
you need to remove all references to spacers inst var since it seems to
be not used anymore now.

another point, try all examples in Morphic-MorphTreeWidget-Examples.
now, the height of each row is constant.
It is because of the RowLayout that is used for MorphTreeNodeMorph
instead of a ProportionalLayout.
see ClassTreeExample before and after your changes.

ClassTreeExample new openOn: Object

cheers
Alain





Reply | Threaded
Open this post in threaded view
|

Re: A lil simplification of MorphTreeNodeMorph

Igor Stasenko
On 5 April 2011 21:39, Alain Plantec <[hidden email]> wrote:

> Le 05/04/2011 20:08, Igor Stasenko a écrit :
>>
>> Cut out some code and extra morphs.
>> It speeds up rendering to 60% of original.
>
> cool
> thanks for reviewing this code!
>>
>> @Benjamin
>> Please verify if it positioning stuff correctly. Because in my image
>> Settings are now OK.
>>
>> @all
>> I need your feedback to know if it works correctly in other places,
>> where tree morph used.
>
> you need to remove all references to spacers inst var since it seems to be
> not used anymore now.
>
> another point, try all examples in Morphic-MorphTreeWidget-Examples.
> now, the height of each row is constant.

Yes, so what it should be instead?

> It is because of the RowLayout that is used for MorphTreeNodeMorph instead
> of a ProportionalLayout.
> see ClassTreeExample before and after your changes.
>
> ClassTreeExample new openOn: Object
>
i will
> cheers
> Alain
>
>
>
>
>
>



--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: A lil simplification of MorphTreeNodeMorph

Tudor Girba
Hi,

60% sounds excellent!

If you are looking into MorphTreeMorph, would it be possible to look into the problem of making the submorphs fill the entire horizontal space?

Let me give you an example:
- download the Glamorous Toolkit image:
http://hudson.moosetechnology.org/job/glamorous-toolkit-latest-dev/lastSuccessfulBuild/artifact/glamoroust/*zip*/glamoroust.zip

- run GTCoder open

- select a package, select a class, expand a method and you will see that the text submorph does not scale either horizontally, or vertically

I also attached a screenshot.

Would it be possible to fix that, too? :)

Cheers,
Doru



On 6 Apr 2011, at 08:57, Igor Stasenko wrote:

> On 5 April 2011 21:39, Alain Plantec <[hidden email]> wrote:
>> Le 05/04/2011 20:08, Igor Stasenko a écrit :
>>>
>>> Cut out some code and extra morphs.
>>> It speeds up rendering to 60% of original.
>>
>> cool
>> thanks for reviewing this code!
>>>
>>> @Benjamin
>>> Please verify if it positioning stuff correctly. Because in my image
>>> Settings are now OK.
>>>
>>> @all
>>> I need your feedback to know if it works correctly in other places,
>>> where tree morph used.
>>
>> you need to remove all references to spacers inst var since it seems to be
>> not used anymore now.
>>
>> another point, try all examples in Morphic-MorphTreeWidget-Examples.
>> now, the height of each row is constant.
>
> Yes, so what it should be instead?
>
>> It is because of the RowLayout that is used for MorphTreeNodeMorph instead
>> of a ProportionalLayout.
>> see ClassTreeExample before and after your changes.
>>
>> ClassTreeExample new openOn: Object
>>
> i will
>> cheers
>> Alain
>>
>>
>>
>>
>>
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
--
www.tudorgirba.com

"Reasonable is what we are accustomed with."


morphtreemorph-not-filling-space.png (43K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: A lil simplification of MorphTreeNodeMorph

Alain Plantec-3
In reply to this post by Igor Stasenko
Le 06/04/2011 08:57, Igor Stasenko a écrit :
>
>> another point, try all examples in Morphic-MorphTreeWidget-Examples.
>> now, the height of each row is constant.
> Yes, so what it should be instead?
it should be dependent on the content height, so as it was before.
another problem is the spacers removal.
now, the horizontal positioning is broken (they was here to take into
account the vertical resizers width)
see the screen shots.

try SimpleGridExample new open before and after the changes.
to exhibit the problem, change the resizerWidth from 2 to 12 as an example
(just set it to 12 in SimpleGridExample>>treeMorph)

I think that MorphTreeMorph can't be efficient for very big lists
because each row may contain a lot of morphs.
This is why I've also implemented LazyMorphTreeMorph.
Try it, it is very much efficient but badly implemented.
I think it should use a background process to build the list
(something like what you did for the annotation pane).

Cheers
Alain

>> It is because of the RowLayout that is used for MorphTreeNodeMorph instead
>> of a ProportionalLayout.
>> see ClassTreeExample before and after your changes.
>>
>> ClassTreeExample new openOn: Object
>>
> i will
>> cheers
>> Alain
>>
>>
>>
>>
>>
>>
>
>


before.png (7K) Download Attachment
after.png (12K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: A lil simplification of MorphTreeNodeMorph

Alain Plantec-3
In reply to this post by Tudor Girba
Le 06/04/2011 09:30, Tudor Girba a écrit :
> Hi,
>
> 60% sounds excellent!
>
> If you are looking into MorphTreeMorph, would it be possible to look into the problem of making the submorphs fill the entire horizontal space?
arrrh! yes sorry,
it is on my todo list and the intergration of the cleaner Gary's
ScrollPane also.
but no time for this now :(
Cheers
Alain

> Let me give you an example:
> - download the Glamorous Toolkit image:
> http://hudson.moosetechnology.org/job/glamorous-toolkit-latest-dev/lastSuccessfulBuild/artifact/glamoroust/*zip*/glamoroust.zip
>
> - run GTCoder open
>
> - select a package, select a class, expand a method and you will see that the text submorph does not scale either horizontally, or vertically
>
> I also attached a screenshot.
>
> Would it be possible to fix that, too? :)
>
> Cheers,
> Doru
>
>
>
>
> On 6 Apr 2011, at 08:57, Igor Stasenko wrote:
>
>> On 5 April 2011 21:39, Alain Plantec<[hidden email]>  wrote:
>>> Le 05/04/2011 20:08, Igor Stasenko a écrit :
>>>> Cut out some code and extra morphs.
>>>> It speeds up rendering to 60% of original.
>>> cool
>>> thanks for reviewing this code!
>>>> @Benjamin
>>>> Please verify if it positioning stuff correctly. Because in my image
>>>> Settings are now OK.
>>>>
>>>> @all
>>>> I need your feedback to know if it works correctly in other places,
>>>> where tree morph used.
>>> you need to remove all references to spacers inst var since it seems to be
>>> not used anymore now.
>>>
>>> another point, try all examples in Morphic-MorphTreeWidget-Examples.
>>> now, the height of each row is constant.
>> Yes, so what it should be instead?
>>
>>> It is because of the RowLayout that is used for MorphTreeNodeMorph instead
>>> of a ProportionalLayout.
>>> see ClassTreeExample before and after your changes.
>>>
>>> ClassTreeExample new openOn: Object
>>>
>> i will
>>> cheers
>>> Alain
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
> --
> www.tudorgirba.com
>
> "Reasonable is what we are accustomed with."
>


Reply | Threaded
Open this post in threaded view
|

Re: A lil simplification of MorphTreeNodeMorph

Igor Stasenko
In reply to this post by Alain Plantec-3
On 6 April 2011 09:45, Alain Plantec <[hidden email]> wrote:

> Le 06/04/2011 08:57, Igor Stasenko a écrit :
>>
>>> another point, try all examples in Morphic-MorphTreeWidget-Examples.
>>> now, the height of each row is constant.
>>
>> Yes, so what it should be instead?
>
> it should be dependent on the content height, so as it was before.
> another problem is the spacers removal.
> now, the horizontal positioning is broken (they was here to take into
> account the vertical resizers width)
> see the screen shots.
>

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.

> try SimpleGridExample new open before and after the changes.
> to exhibit the problem, change the resizerWidth from 2 to 12 as an example
> (just set it to 12 in SimpleGridExample>>treeMorph)
>
> 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 why I've also implemented LazyMorphTreeMorph.
> Try it, it is very much efficient but badly implemented.
> I think it should use a background process to build the list
> (something like what you did for the annotation pane).
>
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.

> Cheers
> Alain


--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: A lil simplification of MorphTreeNodeMorph

Stéphane Ducasse
Hi guys

this is ***REALLLYYYYY*** important that we get scalable List and Tree
so thanks a lot for your effort.
Please continue
Stef

On Apr 6, 2011, at 10:02 AM, Igor Stasenko wrote:

> On 6 April 2011 09:45, Alain Plantec <[hidden email]> wrote:
>> Le 06/04/2011 08:57, Igor Stasenko a écrit :
>>>
>>>> another point, try all examples in Morphic-MorphTreeWidget-Examples.
>>>> now, the height of each row is constant.
>>>
>>> Yes, so what it should be instead?
>>
>> it should be dependent on the content height, so as it was before.
>> another problem is the spacers removal.
>> now, the horizontal positioning is broken (they was here to take into
>> account the vertical resizers width)
>> see the screen shots.
>>
>
> 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.
>
>> try SimpleGridExample new open before and after the changes.
>> to exhibit the problem, change the resizerWidth from 2 to 12 as an example
>> (just set it to 12 in SimpleGridExample>>treeMorph)
>>
>> 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 why I've also implemented LazyMorphTreeMorph.
>> Try it, it is very much efficient but badly implemented.
>> I think it should use a background process to build the list
>> (something like what you did for the annotation pane).
>>
> 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.
>
>> Cheers
>> Alain
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>


Reply | Threaded
Open this post in threaded view
|

Re: A lil simplification of MorphTreeNodeMorph

Tudor Girba
Indeed. For example, in the context of Moose, we sometimes have lists in the order of 100k elements. The LazyMorphTreeMorph offers pagination and it works well, but it would be super cool to have a stronger solution.

Cheers,
Doru

 
On 6 Apr 2011, at 10:08, Stéphane Ducasse wrote:

> Hi guys
>
> this is ***REALLLYYYYY*** important that we get scalable List and Tree
> so thanks a lot for your effort.
> Please continue
> Stef
>
> On Apr 6, 2011, at 10:02 AM, Igor Stasenko wrote:
>
>> On 6 April 2011 09:45, Alain Plantec <[hidden email]> wrote:
>>> Le 06/04/2011 08:57, Igor Stasenko a écrit :
>>>>
>>>>> another point, try all examples in Morphic-MorphTreeWidget-Examples.
>>>>> now, the height of each row is constant.
>>>>
>>>> Yes, so what it should be instead?
>>>
>>> it should be dependent on the content height, so as it was before.
>>> another problem is the spacers removal.
>>> now, the horizontal positioning is broken (they was here to take into
>>> account the vertical resizers width)
>>> see the screen shots.
>>>
>>
>> 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.
>>
>>> try SimpleGridExample new open before and after the changes.
>>> to exhibit the problem, change the resizerWidth from 2 to 12 as an example
>>> (just set it to 12 in SimpleGridExample>>treeMorph)
>>>
>>> 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 why I've also implemented LazyMorphTreeMorph.
>>> Try it, it is very much efficient but badly implemented.
>>> I think it should use a background process to build the list
>>> (something like what you did for the annotation pane).
>>>
>> 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.
>>
>>> Cheers
>>> Alain
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>
>

--
www.tudorgirba.com

"Relationships are of two kinds: those we choose and those that happen. They both matter."






Reply | Threaded
Open this post in threaded view
|

Re: A lil simplification of MorphTreeNodeMorph

Igor Stasenko
In reply to this post by Alain Plantec-3
On 6 April 2011 09:45, Alain Plantec <[hidden email]> wrote:

> Le 06/04/2011 08:57, Igor Stasenko a écrit :
>>
>>> another point, try all examples in Morphic-MorphTreeWidget-Examples.
>>> now, the height of each row is constant.
>>
>> Yes, so what it should be instead?
>
> it should be dependent on the content height, so as it was before.
> another problem is the spacers removal.
> now, the horizontal positioning is broken (they was here to take into
> account the vertical resizers width)
> see the screen shots.
>
> try SimpleGridExample new open before and after the changes.
> to exhibit the problem, change the resizerWidth from 2 to 12 as an example
> (just set it to 12 in SimpleGridExample>>treeMorph)
>

Btw, why in this grid example it uses tree morph?

As to me it sounds a bit of abuse.

Tree morph widget should focus on displaying trees, but not grids.
I think it would be better to use separate widget for representing the grids,
because obviously a data model for grids is not quite same as for
tree, and thus it could use different strategy to generate/represent
grid data.

> I think that MorphTreeMorph can't be efficient for very big lists
> because each row may contain a lot of morphs.
> This is why I've also implemented LazyMorphTreeMorph.
> Try it, it is very much efficient but badly implemented.
> I think it should use a background process to build the list
> (something like what you did for the annotation pane).
>
> Cheers
> Alain
>
>>> It is because of the RowLayout that is used for MorphTreeNodeMorph
>>> instead
>>> of a ProportionalLayout.
>>> see ClassTreeExample before and after your changes.
>>>
>>> ClassTreeExample new openOn: Object
>>>
>> i will
>>>
>>> cheers
>>> Alain
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>
>



--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: A lil simplification of MorphTreeNodeMorph

Alain Plantec-3
In reply to this post by Igor Stasenko
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
>


Reply | Threaded
Open this post in threaded view
|

Re: A lil simplification of MorphTreeNodeMorph

Alain Plantec-3
In reply to this post by Igor Stasenko
Le 06/04/2011 10:23, Igor Stasenko a écrit :

>
> Btw, why in this grid example it uses tree morph?
>
> As to me it sounds a bit of abuse.
>
> Tree morph widget should focus on displaying trees, but not grids.
> I think it would be better to use separate widget for representing the grids,
> because obviously a data model for grids is not quite same as for
> tree, and thus it could use different strategy to generate/represent
> grid data.
ah ah! yes, I agree again that it is not appropriate.
lists and trees are very similar but not grid.
these examples are here to show how to use the widget and for testing
purpose.
btw, It make me remember that nullpointer's solution for grid was much
more efficient. I don't know for the rest but maybe it could be
interesting to
look at it's widgets. maybe all we need is there.
Alain



Reply | Threaded
Open this post in threaded view
|

Re: A lil simplification of MorphTreeNodeMorph

Stéphane Ducasse
In reply to this post by Alain Plantec-3
>>
> 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
>>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: A lil simplification of MorphTreeNodeMorph

Igor Stasenko
Okay, here the updated version.


GTCoder open
looks fine

Settings look fine.
and

SimpleGridExample new open
looking fine as well

--
Best regards,
Igor Stasenko AKA sig.

theTreee.8.cs (9K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: A lil simplification of MorphTreeNodeMorph

Igor Stasenko
and a little more cleanup (should be applied after theTreee)

now a block which responsible for providing an icon for concrete item,
actually could provide a morph,
which means that one could put there an iconic button instead of simple image.


--
Best regards,
Igor Stasenko AKA sig.

Tree2.1.cs (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: A lil simplification of MorphTreeNodeMorph

Alain Plantec-3
Le 06/04/2011 15:14, Igor Stasenko a écrit :
> and a little more cleanup (should be applied after theTreee)
>
> now a block which responsible for providing an icon for concrete item,
> actually could provide a morph,
> which means that one could put there an iconic button instead of simple image.
super.
I've tested and it seems ok for MorphTreeMorph

LazyMorphTreeMorph seems to have row refresh/building problem now.
try with
LazyClassListExample new openOn: Object.
then move the scrollbar to the bottom, then click on the arrow button to
get the entire list
and then scroll manually.
I've observed that some rows are not built correctly now.
I can't be sure that it is due to your improvements

Alain


Reply | Threaded
Open this post in threaded view
|

Re: A lil simplification of MorphTreeNodeMorph

Igor Stasenko
On 6 April 2011 15:52, Alain Plantec <[hidden email]> wrote:

> Le 06/04/2011 15:14, Igor Stasenko a écrit :
>>
>> and a little more cleanup (should be applied after theTreee)
>>
>> now a block which responsible for providing an icon for concrete item,
>> actually could provide a morph,
>> which means that one could put there an iconic button instead of simple
>> image.
>
> super.
> I've tested and it seems ok for MorphTreeMorph
>
> LazyMorphTreeMorph seems to have row refresh/building problem now.
> try with
> LazyClassListExample new openOn: Object.
> then move the scrollbar to the bottom, then click on the arrow button to get
> the entire list
> and then scroll manually.
> I've observed that some rows are not built correctly now.
> I can't be sure that it is due to your improvements
>
hmm.. on my image it works fine.

maybe i didn't included something into changeset... let me take a look

> Alain
>
>
>



--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: A lil simplification of MorphTreeNodeMorph

Igor Stasenko
On 6 April 2011 17:22, Igor Stasenko <[hidden email]> wrote:

> On 6 April 2011 15:52, Alain Plantec <[hidden email]> wrote:
>> Le 06/04/2011 15:14, Igor Stasenko a écrit :
>>>
>>> and a little more cleanup (should be applied after theTreee)
>>>
>>> now a block which responsible for providing an icon for concrete item,
>>> actually could provide a morph,
>>> which means that one could put there an iconic button instead of simple
>>> image.
>>
>> super.
>> I've tested and it seems ok for MorphTreeMorph
>>
>> LazyMorphTreeMorph seems to have row refresh/building problem now.
>> try with
>> LazyClassListExample new openOn: Object.
>> then move the scrollbar to the bottom, then click on the arrow button to get
>> the entire list
>> and then scroll manually.
>> I've observed that some rows are not built correctly now.
>> I can't be sure that it is due to your improvements
>>
> hmm.. on my image it works fine.
>
> maybe i didn't included something into changeset... let me take a look
>

no, it works fine.

>> Alain
>>
>>
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>



--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: A lil simplification of MorphTreeNodeMorph

Igor Stasenko
okay.. i found one bug

forgot to add  cellPositioning: #leftCenter;  for colum wrapper morph


--
Best regards,
Igor Stasenko AKA sig.

Tree2.3.cs (10K) Download Attachment
12