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

Re: [Pharo-project] Issue 2374 in pharo: Dragging a .image in a Windows VM raises an error

by pharo＠googlecode.com

Updates: Labels: -Milestone-1.3 Comment #6 on issue 2374 by marcus.d...(a)gmail.com: Dragging a .image in a Windows VM raises an error http://code.google.com/p/pharo/issues/detail?id=2374 (No comment was entered for this change.)

April 7, 2011

Re: [Pharo-project] Decode url form with Zinc-HTTP

by Sven Van Caekenberghe

On 07 Apr 2011, at 17:37, HernÃ¡n Morales Durand wrote: > One more thing, I've tried to install in the new released Pharo with CogVM: > > Gofer new > squeaksource: 'ZincHTTPComponents'; > package: 'ConfigurationOfZincHTTPComponents'; > load. > (Smalltalk at: #ConfigurationOfZincHTTPComponents) perform: #load > > and loading manually the latest Zinc-HTTP from the Monticello Browser. > > either way I get errors (attached debugger output from the > ConfigurationOf script). What is the proper way to install or update > to the latest version, As described here: http://homepage.mac.com/svc/Zinc-HTTP-Components/ Gofer it squeaksource: 'ZincHTTPComponents'; package: 'Zinc-HTTP'; package: 'Zinc-Tests'; load should always work and load the latest version. The class comment of ConfigurationOfZincHTTPComponents says ConfigurationOfZincHTTPComponents project latestVersion load. I am no expert, so I'll try to rember to ask this at the next Pharo sprint. Sven

April 7, 2011

Re: [Pharo-project] Issue 2349 in pharo: Canonical form for duration

by pharo＠googlecode.com

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

April 7, 2011

Re: [Pharo-project] Issue 2325 in pharo: Sensor shiftPressed always returns false

by pharo＠googlecode.com

Updates: Labels: -Milestone-1.3 Comment #3 on issue 2325 by marcus.d...(a)gmail.com: Sensor shiftPressed always returns false http://code.google.com/p/pharo/issues/detail?id=2325 (No comment was entered for this change.)

April 7, 2011

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

by Alain Plantec

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 ? 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. >

April 7, 2011

Re: [Pharo-project] Issue 2269 in pharo: Smalltalk appendChangesTo: 'myfile.sources'

by pharo＠googlecode.com

Updates: Labels: -Milestone-1.3 Comment #4 on issue 2269 by marcus.d...(a)gmail.com: Smalltalk appendChangesTo: 'myfile.sources' http://code.google.com/p/pharo/issues/detail?id=2269 (No comment was entered for this change.)

April 7, 2011

Re: [Pharo-project] Issue 2265 in pharo: to check MCWorkingCopyBrowser from Squeak

by pharo＠googlecode.com

Updates: Labels: -Milestone-1.3 Comment #4 on issue 2265 by marcus.d...(a)gmail.com: to check MCWorkingCopyBrowser from Squeak http://code.google.com/p/pharo/issues/detail?id=2265 (No comment was entered for this change.)

April 7, 2011

Re: [Pharo-project] Issue 2262 in pharo: Pragma Package

by pharo＠googlecode.com

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

April 7, 2011

Re: [Pharo-project] Issue 2254 in pharo: sorted and sorted: should be moved to TSortable

by pharo＠googlecode.com

Updates: Labels: -Milestone-1.3 Comment #4 on issue 2254 by marcus.d...(a)gmail.com: sorted and sorted: should be moved to TSortable http://code.google.com/p/pharo/issues/detail?id=2254 (No comment was entered for this change.)

April 7, 2011

Re: [Pharo-project] Issue 2235 in pharo: Character Ä is represented as new line

by pharo＠googlecode.com

Updates: Labels: -Milestone-1.3 Comment #9 on issue 2235 by marcus.d...(a)gmail.com: Character Ä is represented as new line http://code.google.com/p/pharo/issues/detail?id=2235 (No comment was entered for this change.)

April 7, 2011