- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Preference refactoring again

by Alain Plantec

StÃ©phane Ducasse a Ã©crit : > sounds cool. > For me the most important aspect is that preferenceCollector (our > current preference class should be a removable layer on top > of the system that are declaring preference. > > Is is correct that > > PreferenceCollector whenChanged: #gradientButtonLook inClass: > PrefProvider notify: self using: #gradientButtonLookIsNow: . > > means that PrefProvider will receive the message > gradientButtonLookIsNow: no, but see the code below: ----------- PrefListener>>initialize super initialize. PreferenceCollector whenChanged: #gradientButtonLook inClass: PrefProvider notify: self using: #gradientButtonLookIsNow: . ----------- it means that a PrefListener instance will receive the #gradientButtonLookIsNow: message each time the preference #gradientButtonLook defined in class PrefProvider is changed. PrefListener and PrefProvider represent can be any class in the system. So, in order to read a preference value an object get it from the provider class by message sending, the provider is a class in a package which defines preferences (no need for PreferenceCollector to get the preference value). > > This way we can push preference to the tools yes > and thety do not have to query the information in the Collector at > run-time yes, Each package have its own preference set in it represented by a set of methods with pragma. When such a package is loaded, its preferences are automatically stored by PreferenceCollector. When a package is removed, its preferences are automatically removed from PreferenceCollector. PreferenceCollector is only here for supporting tools (cool UI ...) and for change notifications. > (hence we could remove Preference and have a more OO design). I guess yes. > > Sorry not to reply earlier (I was breaking yet another wall in our > "kitchen") bon courage :) alain > > Stef > > > On Mar 1, 2009, at 10:05 AM, Alain Plantec wrote: > >> 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 >> >> >> <Zoo-alain_plantec.10.mcz>_______________________________________________ >> >> 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] Fwd: [ANN] 10245

by Tudor Girba

I copied it to the repository of Lukas as well. Does anyone actually see a reason for not having the when:do: method in as an alias to on:do:? I do not see it. Cheers, Doru On 1 Mar 2009, at 10:19, StÃ©phane Ducasse wrote: > Where? > It was not on lukas source and in the pharo inbox > Then there is the question to be sure if we want it. > > > On Mar 1, 2009, at 9:56 AM, Tudor Girba wrote: > >> 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." >> >> >> >> >> _______________________________________________ >> 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 -- www.tudorgirba.com "Be rather willing to give than demanding to get."

March 1, 2009

[Pharo-project] Fwd: Some personal thoughts and questions about Pharo

by StÃ©phane Ducasse

Begin forwarded message: > From: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Date: February 28, 2009 2:07:42 PM CEST > To: Matthew Fulmer <tapplek(a)gmail.com> > Cc: Marcus Denker <denker(a)iam.unibe.ch> > Subject: Re: Some personal thoughts and questions about Pharo > > Hi matthew > > >> Hi. I stumbled across a rather interesting email while I was >> researching to write up my campaign platform for the squeak >> election. Stef wrote this email 4 years ago, and it challenged a >> lot of what I thought about Pharo: >> >> http://lists.squeakfoundation.org/pipermail/squeak-dev/2005-January/087532.… >> >> It prompted me to write this email, and lay out exactly what I >> think about Pharo, both good, bad, and not understood. > > Ok I think that this is important to have a look at what we did and > wrote in the past > to understand our attitude today. Lot of people judge without really > knowing. > > This is not the best email I sent. but it just gives a facett of the > problem > >>> From what I can tell, this email was written just before you >> guys started the 3.9 team. > > I imagine. > >> Firstly, I see that you have really cared about bug response >> latency for a long time. I'm really glad you care and do >> something about it. > > Yes. > We cared also about transparency and trust. > The idea is that I already said that to the squeakfoundation and I > gave up > long time ago. > If we do not give a chance to knowlegdaebale people to get a look then > we failed. Once janko which I trust sent a fix for network and I > thought that > we should integrate it but bert had a look and said it was not good. > So this makes me thing > a lot. So if an opensource movement we do not have communication > then nothing good > can happen. > > For 3.10 I proposed to ralph to help but he declined. They thought > we had no process > and when I explained him what we were doing he said that this is > what he planed to do. > I think that people thiught that ralph was Jesus but he was not. > >> Second, you solved this problem back then by releasing 3.9, >> and now you are solving it thru Pharo. Why did you choose to >> fork this time? >> >> If I may be blunt, I've long suspected that there are exactly >> two reasons why you forked: >> 1. Edgar J. De. Cleene >> 2. Andreas Raab > > You are not blunt > Been called a randomrefactorer is blunt. I do not want to tell more on > that but we are a solid group of people all getting the same feeling > nd this is not > because we are wash-brained. Just our experiences are following the > same line. > Ask mike why andreas does not talk to him. > >> Thirdly, I've heard Stef mention a number of times that "Marcus >> got burned", and therefore doesn't read squeak-dev, or no longer >> runs for board, or several things most squeak people do. >> However, this is by far the earliest mention of said burning >> I've ever seen. I had assumed the burning was people (Edgar and >> Andreas) complaining about Traits, but this was long before >> that. > > marcus was burnt to the point of been sick of smalltalk. > The problem is that marucs dreamt with us at bern about beauty and > a better world and that people like andreas were most of the time > negative and playing for themselves. Look at Tweak Andreas forked it > even people working in Sophie did not have access to his branch. > > >> What is it that happened to Marcus? If you are still bitter >> about something that happened over 4 years ago, perhaps it is >> time to forgive and re-join the squeak community. > > No we are not bitter. The squeak community has no vision except > toying with the past. > If I would be you I would not lose my time there. We harvested since > squeak > 3.6 and we did our best but it failed and it will fail. > >> As 3.11 release team leader, and Squeak board nominee, I'm >> really excited about what you guys are doing with Pharo. From my >> perspective, one thing you have done is take up the reigns for >> harvesting bugs, and left the release team free to consider a >> long-standing issue in the community: who is responsible for >> merging bug fixes from one distribution to another, and how can >> we make their lives easier > > No we did the only thing that make us breath again and not > jump into ruby or python or just hack in our little corner > stuff in VW or other. > Pharo is not an accident this is a survival reflex. > You know when you want to fix sometihng that a guy shout at you > because you push > a fix in his package.... Then after a while you stop this is why > there are some > fonts problem in 39 because we stop to harvest anything related to > andreas. > > >> Another valuable thing you have done is show the community that >> one image does not fit all; the monolithic image does not work >> for anybody. Squeakland showed it does not work for end-users >> Croquet showed it does not work for researchers. > > No Croquet shows nothing. Ask lombardi because he gave a presentation > last year at ESUG and we felt he was just alone lost. > And we are researcher much more than they :). Look at our > publication records. > Now we want a good Smalltalk and make evolve: first class slots, > packages.... > It will take time but we will do it. > >> And now Pharo >> shows that it does not work for developers. I really think that >> Pharo finishes painting that picture in the minds of the >> community, and you have thus paved the way for the release team >> and the squeak board to get away from the monolithic image, and >> toward modularity. I really think the community is ready now, >> and it's all thanks to you guys. I intend to exploit this >> opportunity. > > If you want. But I'm not sure that this is the right analysis. > >> I sent this email in private, because I don't think it would be >> appropriate to ask some of these questions publicly. However, >> feel free to reply to any of this in public, as you see fit. > > Sure I have no secret on that topic. > > >> >> >> -- >> Matthew Fulmer -- http://mtfulmer.wordpress.com/ >> >

March 1, 2009

Re: [Pharo-project] Preference refactoring again

by StÃ©phane Ducasse

sounds cool. For me the most important aspect is that preferenceCollector (our current preference class should be a removable layer on top of the system that are declaring preference. Is is correct that PreferenceCollector whenChanged: #gradientButtonLook inClass: PrefProvider notify: self using: #gradientButtonLookIsNow: . means that PrefProvider will receive the message gradientButtonLookIsNow: This way we can push preference to the tools and thety do not have to query the information in the Collector at run-time (hence we could remove Preference and have a more OO design). Sorry not to reply earlier (I was breaking yet another wall in our "kitchen") Stef On Mar 1, 2009, at 10:05 AM, Alain Plantec wrote: > 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 > > > <Zoo-alain_plantec. > 10.mcz>_______________________________________________ > 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] Fwd: [ANN] 10245

by StÃ©phane Ducasse

Where? It was not on lukas source and in the pharo inbox Then there is the question to be sure if we want it. On Mar 1, 2009, at 9:56 AM, Tudor Girba wrote: > 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." > > > > > _______________________________________________ > 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

[Pharo-project] Fwd: Some personal thoughts and questions about Pharo

by StÃ©phane Ducasse

For the ones that were not there at that time. Study history as always been a way to understand the present :) Begin forwarded message: > From: Matthew Fulmer <tapplek(a)gmail.com> > Date: February 28, 2009 6:26:00 AM CEST > To: Marcus Denker <denker(a)iam.unibe.ch>, St?phane Ducasse <stephane.ducasse(a)inria.fr > > > Cc: Matthew Fulmer <tapplek(a)gmail.com> > Subject: Some personal thoughts and questions about Pharo > > Hi. I stumbled across a rather interesting email while I was > researching to write up my campaign platform for the squeak > election. Stef wrote this email 4 years ago, and it challenged a > lot of what I thought about Pharo: > > http://lists.squeakfoundation.org/pipermail/squeak-dev/2005-January/087532.… > > It prompted me to write this email, and lay out exactly what I > think about Pharo, both good, bad, and not understood. > >> From what I can tell, this email was written just before you > guys started the 3.9 team. > > Firstly, I see that you have really cared about bug response > latency for a long time. I'm really glad you care and do > something about it. > > Second, you solved this problem back then by releasing 3.9, > and now you are solving it thru Pharo. Why did you choose to > fork this time? > > If I may be blunt, I've long suspected that there are exactly > two reasons why you forked: > 1. Edgar J. De. Cleene > 2. Andreas Raab > > Thirdly, I've heard Stef mention a number of times that "Marcus > got burned", and therefore doesn't read squeak-dev, or no longer > runs for board, or several things most squeak people do. > However, this is by far the earliest mention of said burning > I've ever seen. I had assumed the burning was people (Edgar and > Andreas) complaining about Traits, but this was long before > that. > > What is it that happened to Marcus? If you are still bitter > about something that happened over 4 years ago, perhaps it is > time to forgive and re-join the squeak community. > > > As 3.11 release team leader, and Squeak board nominee, I'm > really excited about what you guys are doing with Pharo. From my > perspective, one thing you have done is take up the reigns for > harvesting bugs, and left the release team free to consider a > long-standing issue in the community: who is responsible for > merging bug fixes from one distribution to another, and how can > we make their lives easier > > > Another valuable thing you have done is show the community that > one image does not fit all; the monolithic image does not work > for anybody. Squeakland showed it does not work for end-users > Croquet showed it does not work for researchers. And now Pharo > shows that it does not work for developers. I really think that > Pharo finishes painting that picture in the minds of the > community, and you have thus paved the way for the release team > and the squeak board to get away from the monolithic image, and > toward modularity. I really think the community is ready now, > and it's all thanks to you guys. I intend to exploit this > opportunity. > > I sent this email in private, because I don't think it would be > appropriate to ask some of these questions publicly. However, > feel free to reply to any of this in public, as you see fit. > > -- > Matthew Fulmer -- http://mtfulmer.wordpress.com/ >

March 1, 2009

[Pharo-project] About pharo cut and paste email on Squeak-dev

by StÃ©phane Ducasse

Hi guys I think that we should pay attention that people do not say stupid stuff on us on squeak-dev (even if this is not that important ;) ). Stef

March 1, 2009

[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