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

Re: [Pharo-project] Issue 2454 in pharo: decompiler fix

by pharo＠googlecode.com

Updates: Labels: -Milestone-1.3 Comment #7 on issue 2454 by marcus.d...(a)gmail.com: decompiler fix http://code.google.com/p/pharo/issues/detail?id=2454 (No comment was entered for this change.)

April 7, 2011

Re: [Pharo-project] Issue 2441 in pharo: Strange behavior of Rectangle

by pharo＠googlecode.com

Updates: Labels: -Milestone-1.3 Comment #9 on issue 2441 by marcus.d...(a)gmail.com: Strange behavior of Rectangle http://code.google.com/p/pharo/issues/detail?id=2441 (No comment was entered for this change.)

April 7, 2011

Re: [Pharo-project] An idea about Pluggable widgets

by Igor Stasenko

On 7 April 2011 19:23, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 7 April 2011 18:59, Alain Plantec <alain.plantec(a)yahoo.com> wrote: >> Hi Igor, >> I'm not sure to understand. >> As an example: >> TrafficLight is my model with an action for the red light. >> If I build a view for it, I can use a Button with #performAction: >> >> Button>> performAction >> Â Â ^ model performAction >> >> So, my TrafficLight must implement a #performAction method. >> Now, if I want also an action for the green light performed when another >> button is pressed. >> It means that I've to implement a specific model class for the red and >> another for the green ? > > For that case you use model adapters. > So, then you do something like: > > button1 model: (self for: #performAction adapt: #turnRed) > button2 model: (self for: #performAction adapt: #turnGreen) > > and so, a receiver (which is a model), will receive #turnRed, or > #turnGreen messages, > while button will still use same message for model - #performAction > or alternatively, we could ask a widget to create and install an instance of model adaptor (so it will construct a properly initialized model adaptor, when you only need to fill the data in it): (button1 installModelAdaptorFor: self) actionSelector: #turnRed. (button2 installModelAdaptorFor: self) actionSelector: #turnGreen. >> cheers >> Alain >> >> >> for example, I have a simple UI with two buttons >> >> Le 07/04/2011 15:26, Igor Stasenko a Ã©crit : >>> >>> I have an idea how to refactor the pluggable morphs mess. >>> >>> The main principle behind all pluggables, that you have a model (which >>> is held in instance variable), >>> and then morph having additional ivars to speak with this model, which >>> the selector names you should use >>> to access certain state from model. >>> >>> For example: >>> >>> AlignmentMorph subclass: #PluggableButtonMorph >>> Â Â Â Â instanceVariableNames: 'model label getStateSelector actionSelector >>> getLabelSelector getMenuSelector shortcutCharacter askBeforeChanging >>> triggerOnMouseDown offColor onColor feedbackColor >>> showSelectionFeedback allButtons arguments argumentsProvider >>> argumentsSelector gradientLook enabled actionBlock getColorSelector >>> getEnabledSelector' >>> Â Â Â Â classVariableNames: 'UseGradientLook' >>> Â Â Â Â poolDictionaries: '' >>> Â Â Â Â category: 'Morphic-Pluggable Widgets' >>> >>> >>> as you can see it is crowded with all those ivars, where part of them >>> used to speak with model, >>> and part of them used for keeping flags and additional parameters >>> which you can customize when creating a button. >>> getStateSelector actionSelector getLabelSelector getMenuSelector >>> Â arguments argumentsProvider argumentsSelector gradientLook >>> actionBlock getColorSelector getEnabledSelector >>> >>> and this is really messy.. >>> Take a look at code: >>> >>> performAction >>> Â Â Â Â "Inform the model that this button has been pressed. Sent by the >>> controller when this button is pressed. If the button's actionSelector >>> takes any arguments, they are obtained dynamically by sending the >>> argumentSelector to the argumentsProvider" >>> >>> Â Â Â Â enabled ifFalse: [^self]. >>> Â Â Â Â askBeforeChanging ifTrue: [model okToChange ifFalse: [^ self]]. >>> Â Â Â Â self actionBlock ifNotNil: [ ^ self actionBlock value]. >>> Â Â Â Â actionSelector ifNotNil: >>> Â Â Â Â Â Â Â Â [actionSelector numArgs == 0 >>> Â Â Â Â Â Â Â Â Â Â Â Â ifTrue: [model perform: actionSelector] >>> Â Â Â Â Â Â Â Â Â Â Â Â ifFalse: >>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â [argumentsProvider ifNotNil: >>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â [arguments := argumentsProvider >>> perform: argumentsSelector]. >>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â model perform: actionSelector >>> withArguments: arguments]] >>> >>> >>> Now think if we could replace this with simple: >>> >>> >>> performAction >>> Â Â Â Â "Inform the model that this button has been pressed. Sent by the >>> controller when this button is pressed. If the button's actionSelector >>> takes any arguments, they are obtained dynamically by sending the >>> argumentSelector to the argumentsProvider" >>> >>> Â Â Â Â enabled ifFalse: [^self]. >>> Â Â Â Â model performAction. >>> >>> >>> so, in this case, we just put an obligation onto model to perform any >>> action in response to button clicked, >>> and button no longer cares about crappy logic how it should send a >>> message to model >>> (via action block, via actionSelector ... and whether it should pass >>> any additional arguments or not..) >>> >>> So, in all places which using things in a way like: >>> >>> getListItems >>> Â ^ model perform: getListItemsSelector >>> >>> now will be replaced with clean: >>> >>> getListItems >>> Â ^ model getListItems >>> >>> So, a pluggable morph no longer cares about keeping all those >>> selectors and maintain an obscure logic whether selector is nil or not >>> nil etc etc.. >>> Let model handle it! >>> >>> Then you may ask, what if i have a model, which doesn't implements >>> such protocol (required for specific pluggable widget). >>> The answer is simple: >>> Â - create a pluggable model class for given widget, which wraps around >>> your object and can keeps all those messy 'getLabelSelector' >>> 'getMenuSelector' , >>> inside and mediates between your model and widget. >>> >>> The benefit of it that widgets code will be much more cleaner. >>> And another benefit is that you know what exact protocol is needed if >>> you want to use your object as a model to given widget (list, button >>> etc). >>> And in most of the cases, you don't need to use this messy >>> 'getXYZSelector', because you can simply answer to messages sent by >>> widget and provide >>> necessary data. >>> But if you wanna go messy, you just use wrapper model, which contains >>> all those 'getXYZSelectors' Â which you can set to whatever you like. >>> >> >> >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > -- Best regards, Igor Stasenko AKA sig.

April 7, 2011

Re: [Pharo-project] Issue 2402 in pharo: TCollectionTest and others should provide the collectionClass of the collection under tests

by pharo＠googlecode.com

Updates: Labels: -Milestone-1.3 Comment #2 on issue 2402 by marcus.d...(a)gmail.com: TCollectionTest and others should provide the collectionClass of the collection under tests http://code.google.com/p/pharo/issues/detail?id=2402 (No comment was entered for this change.)

April 7, 2011

[Pharo-project] filesystem changes

by Tudor Girba

Hi, I noticed that Filesystem changed significantly recently both internally and in package structure (I guess it was Colin - the user says cwp). This led to some red tests in Moose that I now fixed. I am writing here to document these changes in case other people are using this nice library. >From a package point of view Filesystem has now a cool structure with basically each category being in a separate package. Furthermore, the original Filesystem is now empty which might create problems if people are loading it like we do in Moose. To get it loading, I created a new baseline (2.0.1-baseline) in the ConfigurationOfFilesystem. There were also some refactorings at the level of the model. Now, FSFilesystem does not have subclasses anymore (e.g., FSDiskFilesystem does not exist anymore). Instead there is a composition with a Store, so you will have FSDiskStore. Thus, if before you used something like "FSDiskFilesystem current", now you will have to use "FSDiskStore currentFilesystem" That was it. Everything is green now in Moose land. Cheers, Doru -- www.tudorgirba.com "Next time you see your life passing by, say 'hi' and get to know her."

April 7, 2011

Re: [Pharo-project] Issue 2438 in pharo: Umlaute Ã¤Ã¶Ã etc in in file/directory names: UTF8 unicode problem?

by pharo＠googlecode.com

Updates: Labels: -Milestone-1.3 Comment #3 on issue 2438 by marcus.d...(a)gmail.com: Umlaute Ã¤Ã¶Ã etc in in file/directory names: UTF8 unicode problem? http://code.google.com/p/pharo/issues/detail?id=2438 (No comment was entered for this change.)

April 7, 2011

Re: [Pharo-project] An idea about Pluggable widgets

by Igor Stasenko

On 7 April 2011 18:59, Alain Plantec <alain.plantec(a)yahoo.com> wrote: > Hi Igor, > I'm not sure to understand. > As an example: > TrafficLight is my model with an action for the red light. > If I build a view for it, I can use a Button with #performAction: > > Button>> performAction > Â Â ^ model performAction > > So, my TrafficLight must implement a #performAction method. > Now, if I want also an action for the green light performed when another > button is pressed. > It means that I've to implement a specific model class for the red and > another for the green ? For that case you use model adapters. So, then you do something like: button1 model: (self for: #performAction adapt: #turnRed) button2 model: (self for: #performAction adapt: #turnGreen) and so, a receiver (which is a model), will receive #turnRed, or #turnGreen messages, while button will still use same message for model - #performAction > cheers > Alain > > > for example, I have a simple UI with two buttons > > Le 07/04/2011 15:26, Igor Stasenko a Ã©crit : >> >> I have an idea how to refactor the pluggable morphs mess. >> >> The main principle behind all pluggables, that you have a model (which >> is held in instance variable), >> and then morph having additional ivars to speak with this model, which >> the selector names you should use >> to access certain state from model. >> >> For example: >> >> AlignmentMorph subclass: #PluggableButtonMorph >> Â Â Â Â instanceVariableNames: 'model label getStateSelector actionSelector >> getLabelSelector getMenuSelector shortcutCharacter askBeforeChanging >> triggerOnMouseDown offColor onColor feedbackColor >> showSelectionFeedback allButtons arguments argumentsProvider >> argumentsSelector gradientLook enabled actionBlock getColorSelector >> getEnabledSelector' >> Â Â Â Â classVariableNames: 'UseGradientLook' >> Â Â Â Â poolDictionaries: '' >> Â Â Â Â category: 'Morphic-Pluggable Widgets' >> >> >> as you can see it is crowded with all those ivars, where part of them >> used to speak with model, >> and part of them used for keeping flags and additional parameters >> which you can customize when creating a button. >> getStateSelector actionSelector getLabelSelector getMenuSelector >> Â arguments argumentsProvider argumentsSelector gradientLook >> actionBlock getColorSelector getEnabledSelector >> >> and this is really messy.. >> Take a look at code: >> >> performAction >> Â Â Â Â "Inform the model that this button has been pressed. Sent by the >> controller when this button is pressed. If the button's actionSelector >> takes any arguments, they are obtained dynamically by sending the >> argumentSelector to the argumentsProvider" >> >> Â Â Â Â enabled ifFalse: [^self]. >> Â Â Â Â askBeforeChanging ifTrue: [model okToChange ifFalse: [^ self]]. >> Â Â Â Â self actionBlock ifNotNil: [ ^ self actionBlock value]. >> Â Â Â Â actionSelector ifNotNil: >> Â Â Â Â Â Â Â Â [actionSelector numArgs == 0 >> Â Â Â Â Â Â Â Â Â Â Â Â ifTrue: [model perform: actionSelector] >> Â Â Â Â Â Â Â Â Â Â Â Â ifFalse: >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â [argumentsProvider ifNotNil: >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â [arguments := argumentsProvider >> perform: argumentsSelector]. >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â model perform: actionSelector >> withArguments: arguments]] >> >> >> Now think if we could replace this with simple: >> >> >> performAction >> Â Â Â Â "Inform the model that this button has been pressed. Sent by the >> controller when this button is pressed. If the button's actionSelector >> takes any arguments, they are obtained dynamically by sending the >> argumentSelector to the argumentsProvider" >> >> Â Â Â Â enabled ifFalse: [^self]. >> Â Â Â Â model performAction. >> >> >> so, in this case, we just put an obligation onto model to perform any >> action in response to button clicked, >> and button no longer cares about crappy logic how it should send a >> message to model >> (via action block, via actionSelector ... and whether it should pass >> any additional arguments or not..) >> >> So, in all places which using things in a way like: >> >> getListItems >> Â ^ model perform: getListItemsSelector >> >> now will be replaced with clean: >> >> getListItems >> Â ^ model getListItems >> >> So, a pluggable morph no longer cares about keeping all those >> selectors and maintain an obscure logic whether selector is nil or not >> nil etc etc.. >> Let model handle it! >> >> Then you may ask, what if i have a model, which doesn't implements >> such protocol (required for specific pluggable widget). >> The answer is simple: >> Â - create a pluggable model class for given widget, which wraps around >> your object and can keeps all those messy 'getLabelSelector' >> 'getMenuSelector' , >> inside and mediates between your model and widget. >> >> The benefit of it that widgets code will be much more cleaner. >> And another benefit is that you know what exact protocol is needed if >> you want to use your object as a model to given widget (list, button >> etc). >> And in most of the cases, you don't need to use this messy >> 'getXYZSelector', because you can simply answer to messages sent by >> widget and provide >> necessary data. >> But if you wanna go messy, you just use wrapper model, which contains >> all those 'getXYZSelectors' Â which you can set to whatever you like. >> > > > -- Best regards, Igor Stasenko AKA sig.

April 7, 2011

Re: [Pharo-project] Issue 2394 in pharo: Halt

by pharo＠googlecode.com

Updates: Labels: -Milestone-1.3 Comment #6 on issue 2394 by marcus.d...(a)gmail.com: Halt http://code.google.com/p/pharo/issues/detail?id=2394 (No comment was entered for this change.)

April 7, 2011

Re: [Pharo-project] Issue 2398 in pharo: Scoped System Reflection (reconciling BrowserEnvironment)

by pharo＠googlecode.com

Updates: Labels: -Milestone-1.3 Comment #2 on issue 2398 by marcus.d...(a)gmail.com: Scoped System Reflection (reconciling BrowserEnvironment) http://code.google.com/p/pharo/issues/detail?id=2398 (No comment was entered for this change.)

April 7, 2011

Re: [Pharo-project] Issue 2388 in pharo: Display graphics in FileList

by pharo＠googlecode.com

Updates: Labels: -Milestone-1.3 Comment #6 on issue 2388 by marcus.d...(a)gmail.com: Display graphics in FileList http://code.google.com/p/pharo/issues/detail?id=2388 (No comment was entered for this change.)

April 7, 2011