April 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] A lil simplification of MorphTreeNodeMorph

by Alain Plantec

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 >

April 6, 2011

Re: [Pharo-project] Actions done in 1.3

by laurent laffont

On Wed, Apr 6, 2011 at 10:17 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > Planning is also important. > > Time is good, but another thing is i think we should think about, > what features we want to be in new release, and do not release until > they delivered. > I don't really like this. I prefer rhythm, agility. Timeboxing enables maximum value in each release. If a feature is really important, it will be on time. If not on time, it means it was no so important. Always green test is a must-have. > Besides bug fixing and minor improvements, there should be some > functionality which we want to have in new release, > That should be a goal, but don't delay a release because the feature is not here. If releases are often ( for example every 3 months), shorter, it won't be a big problem to wait for the next one. I prefer to have a release *now* without my feature and wait 3 months for the next release than no release and waiting for 3 months more with less and less energy. Laurent. > so then you could say: 1.x is better than previous because of A,B,C, > but not because a,b,c ( capital letters is major stuff, while regular > ones is for minor stuff ) :) > > > On 6 April 2011 10:01, Serge Stinckwich <serge.stinckwich(a)gmail.com> > wrote: > > On Wed, Apr 6, 2011 at 12:56 PM, laurent laffont > > <laurent.laffont(a)gmail.com> wrote: > >> On Tue, Apr 5, 2011 at 10:49 PM, Mariano Martinez Peck > >> <marianopeck(a)gmail.com> wrote: > >>> > >>> Yes!!! totally agree. Now that we release 1.2, I would freeze and > release > >>> PharoCore 1.3 beta. Update the link to stable pharo to that, and start > >>> trying to load the dev tools there. > >> > >> +10 > >> And propose a fixed date for release - no compromise, will be release at > >> this date. > > > > +1 > > Timeboxing sounds great. > > Podomoro for software development ;-) > > > > Regards, > > -- > > Serge Stinckwich > > UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam > > Every DSL ends up being Smalltalk > > http://doesnotunderstand.org/ > > > > > > > > -- > Best regards, > Igor Stasenko AKA sig. > >

April 6, 2011

Re: [Pharo-project] A lil simplification of MorphTreeNodeMorph

by Igor Stasenko

On 6 April 2011 09:45, Alain Plantec <alain.plantec(a)yahoo.com> 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.

April 6, 2011

Re: [Pharo-project] A lil simplification of MorphTreeNodeMorph

by 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 <alain.plantec(a)yahoo.com> 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."

April 6, 2011

Re: [Pharo-project] Actions done in 1.3

by Igor Stasenko

Planning is also important. Time is good, but another thing is i think we should think about, what features we want to be in new release, and do not release until they delivered. Besides bug fixing and minor improvements, there should be some functionality which we want to have in new release, so then you could say: 1.x is better than previous because of A,B,C, but not because a,b,c ( capital letters is major stuff, while regular ones is for minor stuff ) :) On 6 April 2011 10:01, Serge Stinckwich <serge.stinckwich(a)gmail.com> wrote: > On Wed, Apr 6, 2011 at 12:56 PM, laurent laffont > <laurent.laffont(a)gmail.com> wrote: >> On Tue, Apr 5, 2011 at 10:49 PM, Mariano Martinez Peck >> <marianopeck(a)gmail.com> wrote: >>> >>> Yes!!! totally agree.Â Now that we release 1.2, I would freeze and release >>> PharoCore 1.3 beta.Â Update the link to stable pharo to that, and start >>> trying to load the dev tools there. >> >> +10 >> And propose a fixed date for release - no compromise, will be release at >> this date. > > +1 > Timeboxing sounds great. > Podomoro for software development ;-) > > Regards, > -- > Serge Stinckwich > UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam > Every DSL ends up being Smalltalk > http://doesnotunderstand.org/ > > -- Best regards, Igor Stasenko AKA sig.

April 6, 2011

Re: [Pharo-project] abouth nautilus and the removal of CodeHolder hierarchy

by Fernando Olivero

what about my initial question? it got buried beneath other discussions in this thread. Ben, can you give your opinion ? Im interested because for the SMx port, this would help in narrowing the classes to import. Fernando On Wed, Apr 6, 2011 at 9:08 AM, Tudor Girba <tudor.girba(a)gmail.com> wrote: > Hi, > > On 6 Apr 2011, at 08:16, Alain Plantec wrote: > >> Le 05/04/2011 22:03, Alain Plantec a Ã©crit : >>> Le 05/04/2011 20:57, StÃ©phane Ducasse a Ã©crit : >>>> A new browser :) >>>> Supporting >>>> Â Â - groups >>>> Â Â - package >>>> Â Â - declarative menus >>>> Â Â - environment selection >>>> Â Â - scoped actions >>>> Â Â - soon refactoring >>>> >>>> but right now a bit too slow because of the HUGGGGGGEEEEEE trees build by TreeMorphTreeMorph >>> yes, maybe MorphTreeMorph is not the good tree to use here. >>> why not use a simpler one ? >> or try with LazyMorphTreeMorph even it should be improved. (it should be changed to build the list in background). > > That would be super cool :) > > Doru > > >>> Alain >>> >>>>> Squeaksource simply says "A new browser" >>>>> >>>>> Cheers, >>>>> Alexandre >>>> >>>> >>> >>> >>> >> >> > > -- > www.tudorgirba.com > > "Presenting is storytelling." > > >

April 6, 2011

Re: [Pharo-project] Draft Pharo 1.2.1 Release Announcement

by Mariano Martinez Peck

I think this part is wrong (see screenshot) On Wed, Apr 6, 2011 at 10:05 AM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > On Apr 5, 2011, at 22:27 , Adrian Lienhard wrote: > > > As far as I see there's one thing missing on the website: the download > sticker for the one click image (top right on the page) still points to > 1.1.1. I'll try to change the sticker and link tomorrow morning. > > The new sticker is online. I've linked to the non-COG one-click image. Is > that what we want? > > I've also updated the one-click image links on > http://www.pharo-project.org/pharo-download > > So, as far as I can tell, the website is ready. > > Cheers > Adrian > -- Mariano http://marianopeck.wordpress.com

April 6, 2011

Re: [Pharo-project] A lil simplification of MorphTreeNodeMorph

by 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 <alain.plantec(a)yahoo.com> 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. >

April 6, 2011

Re: [Pharo-project] Draft Pharo 1.2.1 Release Announcement

by Adrian Lienhard

On Apr 5, 2011, at 22:27 , Adrian Lienhard wrote: > As far as I see there's one thing missing on the website: the download sticker for the one click image (top right on the page) still points to 1.1.1. I'll try to change the sticker and link tomorrow morning. The new sticker is online. I've linked to the non-COG one-click image. Is that what we want? I've also updated the one-click image links on http://www.pharo-project.org/pharo-download So, as far as I can tell, the website is ready. Cheers Adrian

April 6, 2011

Re: [Pharo-project] A lil simplification of MorphTreeNodeMorph

by Igor Stasenko

On 6 April 2011 09:45, Alain Plantec <alain.plantec(a)yahoo.com> 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.

April 6, 2011