March 2009 - Pharo-dev - lists.pharo.org

[Pharo-project] Preference refactoring again

by Alain Plantec

Hi all, joined Zoo package is a attempt to translate in code what we discussed here before about preference refactoring. The framework is made of 3 classes: PreferenceCollector, PreferenceDefinition and PreferenceValue. In Zoo there are also 2 classes for testing: PrefProvider and PrefChangeListener. PrefProvider class declares some preferences and PrefChangeListener is here to test preference change notification. PrefChangeListener>>initialize super initialize. PreferenceCollector whenChanged: #gradientButtonLook inClass: PrefProvider notify: self using: #gradientButtonLookIsNow: . PreferenceCollector whenChanged: #gradientButtonLook inClass: PrefProvider notify: self using: #gradientLook: PrefChangeListener class>>test "self test" PrefChangeListener new inspect. PrefProvider gradientButtonLook: PrefProvider gradientButtonLook value not. PrefProvider gradientButtonLook: PrefProvider gradientButtonLook value not. PrefProvider gradientButtonLook: PrefProvider gradientButtonLook value not. From PreferenceCollector comment: -------------------------------------- A PreferenceCollector automatically collects all preferences. A preference is represented by a PreferenceDefinition. All PreferenceDefinition are stored in the preferences instance variable. Instance Variables preferences: OrderedCollection of PreferenceDefinition preferences - contains all PreferenceDefinition which are automatically built from pragma found in preference getters ADDING A PREFERENCE PreferenceCollector makes use of the SystemChangeNotifier in order to automate the adding, the removing and the updating of preferences. See #PreferenceCollector>>event: to see how preferences update is implemented. Editing a new method with a preference pragma or inserting a preference pragma in an existing method are the two ways for preference definition adding. The only way to remove a preference definition is to remove the corresponding method. Example of a "blackAndWhite" preference. Methods below are defined by the preference provider APreferencePrivider class. Note that the value stored in BlackAndWhite class variable is an instance of PreferenceValue. In this example, the default value is directly given with the pragma: ------------- APreferencePrivider class>>blackAndWhite <preference: 'Use black and white' type: #Boolean set: #blackAndWhite: defaultValue: false description: 'Use black and white'> ^ BlackAndWhite ifNil: [BlackAndWhite := PreferenceValue value: false location: self selector: #blackAndWhite] APreferencePrivider class>>blackAndWhite: aBoolean self blackAndWhite value: aBoolean ------------- If a default value can't be specified in the pragma, another way consists in using a selector which represents the message to send to the class in order to get the default value: ------------- APreferencePrivider class>>standardFont <preference: 'The default system font' type: #LogicalFont set: #standardFont: default: #defaultStandardFont description: 'The default system font'> ^ StandardFont ifNil: [StandardFont := PreferenceValue value: self defaultStandardFont location: self selector: #standardFont] APreferencePrivider class>>standardFont: aFont self standardFont value: aFont APreferencePrivider class>>defaultStandardFont ^ LogicalFont familyName: 'Arial' fallbackFamilyNames: nil pointSize: 12 stretchValue: 5 weightValue: 400 slantValue: 0 ------------- LISTENING TO A PREFERENCE VALUE CHANGE Any object can register itself as a preference value change listener. See #PreferenceCollector class>>whenChanged: inClass:notify:using:. Each time a preference value is changed, #preference: inClass:changedWith: is sent to the PreferenceCollector class. Example of code a listener can implement in order to be notified each time a gradientButtonLook preference defined by a PrefProvider class is changed. In this example, the listener ask to be notified by a send of #gradientButtonLookIsNow: message. The argument given to gradientButtonLookIsNow: is the new preference value. ------------- .... PreferenceCollector whenChanged: #gradientButtonLook inClass: PrefProvider notify: self using: #gradientButtonLookIsNow:. .... ------------- What do you think ? cheers Alain

March 1, 2009

Re: [Pharo-project] Fwd: [ANN] 10245

by Tudor Girba

Hi Stef, > Some more happy people :) > > - Announcements-lr.10 from souce.lukas-renggli.ch > Is when:do: not missing for compatibility with VW? I published a new version containing when:do: Announcements-tg.11. Cheers, Doru > > - Polymorph > Fix for button for currently selected window in tasklist not being > differentiated when using Watery 2 theme. > > - ContextPart argument > > - merged Issue 608: saveAsNewVersion uses deprecated method > > - Issue 614: > MessageTally broken when invoked from non-GUI process (e.g., in > Seaside code) > > > Now we should really kill more items for the milestone 1.0. > > Stef (now breakfast :) > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com "Yesterday is a fact. Tomorrow is a possibility. Today is a challenge."

March 1, 2009

[Pharo-project] Fwd: [squeak-dev] recategorize a bunch

by StÃ©phane Ducasse

Begin forwarded message: > From: Eliot Miranda <eliot.miranda(a)gmail.com> > Date: March 1, 2009 8:08:46 AM CEST > To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org > > > Subject: Re: [squeak-dev] recategorize a bunch > Reply-To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org > > > > > > On Sat, Feb 28, 2009 at 7:42 PM, Sebastian Sastre <ssastre(a)seaswork.com > > wrote: > hi there, while loading some stuff of mine form an image to another, > I was > annoyed/surprised by not finding some methods. Then I've figured out > that all > not imported methods where missing because somehow they happen to be > under a > category named *-changed some others under *-compilation-issues. > > There is a way I can query the system (monticello?) to get the whole > and set > them another category (so I can save the packageproperly)? > > Let's say that SystemNavigation>>allMethodsInCatergory: answers > MethodReference instances instead of 'Classd>selector' string > thingies, and if it doesn't that it can by defining it as > > SystemNavigation methods for query > allMethodsInCategory: category > | aCollection | > aCollection := Set new. > Cursor wait showWhile: > [self allBehaviorsDo: > [:x | > ((category = ClassOrganizer allCategory > ifTrue: [x organization allMethodSelectors] > ifFalse: [x organization listAtCategoryNamed: category])) do: > [:sel | aCollection add: (MethodReference new setStandardClass: > x methodSymbol: sel)]]]. > ^aCollection. > > then you want to say > > (SystemNavigation default allMethodsInCategory: #'* whatever the > category * was called') do: > [:mr| > mr actualClass organization > classify: mr methodSymbol > under: #'what I would like the category to be'] > > > > thanks, > > sebastian > > > >

March 1, 2009

[Pharo-project] Fwd: [ANN] 10245

by StÃ©phane Ducasse

Some more happy people :) - Announcements-lr.10 from souce.lukas-renggli.ch Is when:do: not missing for compatibility with VW? - Polymorph Fix for button for currently selected window in tasklist not being differentiated when using Watery 2 theme. - ContextPart argument - merged Issue 608: saveAsNewVersion uses deprecated method - Issue 614: MessageTally broken when invoked from non-GUI process (e.g., in Seaside code) Now we should really kill more items for the milestone 1.0. Stef (now breakfast :)

March 1, 2009

Re: [Pharo-project] Fixing Polymorph overrides

by StÃ©phane Ducasse

Excellent! Stef On Mar 1, 2009, at 3:49 AM, Gary Chambers wrote: > Fair enough. I can make a new package for the overrides specifically > for > Squeak. Will just have to be careful when (if) new overrides are > needed for > Squeak and then to somehow make available for Pharo. > > Regards, Gary > > ----- Original Message ----- > From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Saturday, February 28, 2009 9:15 PM > Subject: Re: [Pharo-project] Fixing Polymorph overrides > > > Would be an excellent way to do it :) > > On Feb 28, 2009, at 10:09 PM, Michael Rueger wrote: > >> StÃ©phane Ducasse wrote: >>> Ideally we would like to have no overrides. >>> Now any solution going into that direction would be a good step. >> >> Would it be possible to integrate the overrides into Pharo and them >> make >> a compatibility package for Squeak that adds those overrides to >> Squeak >> before loading Polymorph? >> >> Michael >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 1, 2009

Re: [Pharo-project] Fixing Polymorph overrides

by Gary Chambers

Fair enough. I can make a new package for the overrides specifically for Squeak. Will just have to be careful when (if) new overrides are needed for Squeak and then to somehow make available for Pharo. Regards, Gary ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Saturday, February 28, 2009 9:15 PM Subject: Re: [Pharo-project] Fixing Polymorph overrides Would be an excellent way to do it :) On Feb 28, 2009, at 10:09 PM, Michael Rueger wrote: > StÃ©phane Ducasse wrote: >> Ideally we would like to have no overrides. >> Now any solution going into that direction would be a good step. > > Would it be possible to integrate the overrides into Pharo and them > make > a compatibility package for Squeak that adds those overrides to Squeak > before loading Polymorph? > > Michael > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 1, 2009

Re: [Pharo-project] Sophie rome vs a cairo binding

by Gary Chambers

Canvas would be good to abstract for more backends. Same ethos can apply to higher-level ui things too. Will be needed I think. Consider Polymorph as an experiment into what is possible. Should be able to distill things from that in a more general sense along with the flexibility of host windows etc. Regards, Gary ----- Original Message ----- From: "Michael Rueger" <m.rueger(a)acm.org> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Saturday, February 28, 2009 7:25 PM Subject: Re: [Pharo-project] Sophie rome vs a cairo binding StÃ©phane Ducasse wrote: > Hi > > I would like to understand the difference between rome (the package in > sophie) and > a cairo binding such that one of squeak-GTK. I'm not sure how the GTK bindings work, so can't say anything about that. Rome is more than just a Cairo binding, it is basically a new Canvas hierarchy that support different back-ends. Currently supported are Cairo and Balloon, but it could be possible to add a BitBlt based backend as well. Or native bindings to Direct-X etc. So in my eyes Rome could be a way to migrate off of the current inconsistent Canvas zoo onto something consistent and extensible. But then I'm slightly biased ;-) Michael _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 1, 2009