- Pharo-dev - lists.pharo.org

Re: [Pharo-project] jtalk fun

by Nicolas Petton

Le mercredi 06 avril 2011 Ã 12:28 +0200, Noury Bouraqadi a Ã©crit : > Cool. But how do we move parts? Hmm, you don't... I only wrote the field and pieces, the game isn't working yet (and I didn't think someone would find it... kudos to Laurent :-) Cheers, Nico > > > On 5 avr. 2011, at 15:16, laurent laffont wrote: > > > Go to http://jtalk-project.org/ > > > > Open development tools -> Workspace > > > > Evaluate: > > > > Tetris new appendToJQuery: 'body' asJQuery > > > > play. > > > > > > Laurent. > > Noury Bouraqadi > http://car.mines-douai.fr/noury > -- > -6th National Conference on > âControl Architecture of Robotsâ > 24-25 may 2011, Grenoble area, France > http://car2011.inrialpes.fr/ > > -19th ESUG International Smalltalk Conference > 22-26 August 2011, Edinburgh, UK > http://www.esug.org/Conferences/2011 > > -19Ã¨mes JournÃ©es Francophones sur les SystÃ¨mes Multi-Agents (JFSMAâ11) > http://www.univ-valenciennes.fr/congres/jfsma2011/ > 17-19 Octobre 2011, Valenciennes, France > > > > > > -- Nicolas Petton http://www.nicolas-petton.fr

April 6, 2011

Re: [Pharo-project] jtalk fun

by Noury Bouraqadi

Cool. But how do we move parts? On 5 avr. 2011, at 15:16, laurent laffont wrote: > Go to http://jtalk-project.org/ > > Open development tools -> Workspace > > Evaluate: > > Tetris new appendToJQuery: 'body' asJQuery > > play. > > > Laurent. Noury Bouraqadi http://car.mines-douai.fr/noury -- -6th National Conference on âControl Architecture of Robotsâ 24-25 may 2011, Grenoble area, France http://car2011.inrialpes.fr/ -19th ESUG International Smalltalk Conference 22-26 August 2011, Edinburgh, UK http://www.esug.org/Conferences/2011 -19Ã¨mes JournÃ©es Francophones sur les SystÃ¨mes Multi-Agents (JFSMAâ11) http://www.univ-valenciennes.fr/congres/jfsma2011/ 17-19 Octobre 2011, Valenciennes, France

April 6, 2011

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

by Alain Plantec

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

April 6, 2011

Re: [Pharo-project] [COTDC] 42 - ExpanderMorphContracted

by laurent laffont

Yeah coooool ! Laurent On Wed, Apr 6, 2011 at 10:46 AM, Gary Chambers <gazzaguru2(a)btinternet.com>wrote: > "I am an Announcement that occurs when an ExpanderMorph is contracted > (rolled-up). > > Example where visibility of another UI component depends on the > expanded/contracted state of Expander 2 > > |builder expanders ex1 ex2 text list row| > builder := UITheme builder. > expanders := builder newColumn: { > ex1 := builder newExpander: 'Expander 1'. > ex2 := builder newExpander: 'Expander 2'}. > expanders > width: 100; > hResizing: #rigid. > text := builder > newTextEditorFor: (ValueHolder new contents: 'Some text') > getText: #contents setText: #contents:. > list := (builder > newListFor: (ListModel new list: #('One' 'Two' 'Three' 'Four'); > selectionIndex: 3) > list: #list selected: #selectionIndex changeSelected: #selectionIndex: > help: 'This is a list') > minWidth: 120; > visible: false; > disableTableLayout: true. > ex2 announcer > when: ExpanderMorphContracted do: [list hide; disableTableLayout: true]; > when: ExpanderMorphExpanded do: [list show; disableTableLayout: false]. > row := builder newRow: { > expanders. > (builder newRow: {text. list}) > vResizing: #spaceFill}. > (row openInWindowLabeled: 'Expander Announcements Example') extent: > 400@300 > > " > > Regards, Gary > > ----- Original Message ----- > *From:* laurent laffont <laurent.laffont(a)gmail.com> > *To:* An open mailing list to discuss any topics related to an > open-sourceSmalltalk <pharo-project(a)lists.gforge.inria.fr> > *Sent:* Tuesday, April 05, 2011 7:32 PM > *Subject:* [Pharo-project] [COTDC] 42 - ExpanderMorphContracted > > Today: ExpanderMorphContracted > > > Comment Of The Day Contest - One Day One Comment > Rules: > #1: Each day a not commented class is elected. Each day the best comment > will be integrated with name of the author(s). > #2: If you cannot comment it, deprecate it. > Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest > > Laurent > >

April 6, 2011

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

by Adrian Lienhard

Thanks for checking, Mariano. I fixed it. Adrian On Apr 6, 2011, at 10:09 , Mariano Martinez Peck wrote: > 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 > > <Screen shot 2011-04-06 at 10.08.49 AM.png>

April 6, 2011

Re: [Pharo-project] [COTDC] 42 - ExpanderMorphContracted

by Gary Chambers

"I am an Announcement that occurs when an ExpanderMorph is contracted (rolled-up). Example where visibility of another UI component depends on the expanded/contracted state of Expander 2 |builder expanders ex1 ex2 text list row| builder := UITheme builder. expanders := builder newColumn: { ex1 := builder newExpander: 'Expander 1'. ex2 := builder newExpander: 'Expander 2'}. expanders width: 100; hResizing: #rigid. text := builder newTextEditorFor: (ValueHolder new contents: 'Some text') getText: #contents setText: #contents:. list := (builder newListFor: (ListModel new list: #('One' 'Two' 'Three' 'Four'); selectionIndex: 3) list: #list selected: #selectionIndex changeSelected: #selectionIndex: help: 'This is a list') minWidth: 120; visible: false; disableTableLayout: true. ex2 announcer when: ExpanderMorphContracted do: [list hide; disableTableLayout: true]; when: ExpanderMorphExpanded do: [list show; disableTableLayout: false]. row := builder newRow: { expanders. (builder newRow: {text. list}) vResizing: #spaceFill}. (row openInWindowLabeled: 'Expander Announcements Example') extent: 400@300 " Regards, Gary ----- Original Message ----- From: laurent laffont To: An open mailing list to discuss any topics related to an open-sourceSmalltalk Sent: Tuesday, April 05, 2011 7:32 PM Subject: [Pharo-project] [COTDC] 42 - ExpanderMorphContracted Today: ExpanderMorphContracted Comment Of The Day Contest - One Day One Comment Rules: #1: Each day a not commented class is elected. Each day the best comment will be integrated with name of the author(s). #2: If you cannot comment it, deprecate it. Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest Laurent

April 6, 2011

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