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

Re: [Pharo-project] Preferences refactoring

by Alain Plantec

Alain Plantec a Ã©crit : > Gary Chambers a Ã©crit : > >> Not sure I like having the code changed all the time. >> If the code is changed then the MC package will show changes... >> > ok, but I liked the idea of not to have variable for simple preferences. > and not to be forced to use a particular tool or an inspector in order to change a preference. just use your favorite browser. alain > a solution could be to use update notification. in the case of a > preference -> do not implies package change. > But I can agry with your solution easily. :) > .....

Feb. 16, 2009

Re: [Pharo-project] Preferences refactoring

by Alain Plantec

Gary Chambers a Ã©crit : > Not sure I like having the code changed all the time. > If the code is changed then the MC package will show changes... ok, but I liked the idea of not to have variable for simple preferences. a solution could be to use update notification. in the case of a preference -> do not implies package change. But I can agry with your solution easily. :) > > The Pragma could instead specify how to set the preference (variable > defined by the class/instance that declares the pragma). maybe no need for that by default: for a preference named "myPreference" in class X, one can have, by default, X class>>myPreference and X class>>myPreference: first case with implicit setter: X class>>myPreference <preferenceType: T defaultValue: aTValue> ^ myPreference ifNil: [myPreference := aTValue] Or X class>>myPreference <preferenceType: T defaultGetter: #(how to get default)> ^ myPreference ifNil: [myPreference := ahow to get default] And X class>>myPreference: aTValue myPreference := aTValue second case with explicit setter: X class>>myPreference <preferenceType: T defaultValue: aTValue setter: #anothetSetter:> ^ myPreference ifNil: [myPreference := aTValue] Or X class>>myPreference <preferenceType: T defaultGetter: #(how to get default) setter: #anothetSetter:> ^ myPreference ifNil: [myPreference := ahow to get default] And X class>>anothetSetter: aTValue myPreference := aTValue Remark about implicit case: Usually I don't like implicit things but, here it can be a way to implement extensions (as helpers are) Possible implicit methods : X class>>myPreference: aTValue myPreference := aTValue X class>>myPreferenceHelpText ^ 'help text the helper need' X class>>myPreferenceGroups ^ #(#Morphic #Colors) X class>>myPreference<Something> ^ "something used somewhere" Cheers alain > > Regards, Gary > > ----- Original Message ----- From: "Alain Plantec" <beranger22(a)gmail.com> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Monday, February 16, 2009 12:25 PM > Subject: Re: [Pharo-project] Preferences refactoring > > > Here is a first proposition: > > preference declaration: a class method with pragma. > In the image, a preference is stored as a Pragma instance (no Preference > class). > Actual preferences can be stored into a set of Pragma. > One can use a dictionary (a class variable somewhere) in order to store > several named preference set. > Installing a preference set is done by the loading (code compilation) > of all pragmas of the preference set. > > Example: > AClassSomewhere>>loadPreferencesFrom: aSetOfPragma > aSetOfPragma do: [:p | (p method methodReference > asMethodDefinition) load] > > Preference method > two kinds: value preference object preference > - simple preference: a preference which type is a literal type > > examples: > ChangeSet class>>checkForSlips > <preferenceType: #Boolean defaultValue: true> > ^ true > > HTTPSocket class>>httpProxyPort > <preferenceType: #Integer defaultValue: 80> > ^ 80 > > - object preference: a preference which type is any class, such a > preference method return a "complex" object instance. > the value is stored in a class instance variable which name is the > preference name. the variable initialization is lazy. > the value as well as the default value are the result of a message send > to a particular class. > example with font: > > AClassSomewhere class>>standardFont > <preferenceType: #LogicalFont defaultGetter: #(#LogicalFont > #familyName: 'Arial' #fallbackFamilyNames: nil #pointSize: 12 > #stretchValue: 5 #weightValue: 400 #slantValue: 0)> > ^ standardFont > ifNil: [standardFont := LogicalFont > familyName: 'Arial' > fallbackFamilyNames: nil > pointSize: 12 > stretchValue: 5 > weightValue: 400 > slantValue: 0] > > Interoperability with file system: > File in/out via standard code file, cool :) > All we need is present, mainly, we have MCStWriter and MCStReader > > Tested example: > stream := RWBinaryOrTextStream on: String new. > writer := MCStWriter on: stream. > "collecting and writing" > PreferenceCollector allPreferencePragmas do: [ :p | (p method > methodReference asMethodDefinition) accept: writer]. > "reading and loading" > reader := MCStReader on: stream readStream. > reader definitions do: [:d | d load]. > > Changing a preference value: > It can be simply done via code editing (no particular tool is mandatory) > > Helpers > What we need: a cool tool to set preference values (actual > PreferenceBrowser replacement) > Let's call it PreferencesSetter (better name ?) > PreferenceSetter needs an helper builder for each individual preference > type. > For a particular preference (stored as a Pragma instance), The > PreferenceSetter tool ask the preference type class (found in the Pragma > instance) > to build the helper. > as an example, we need an helper in order to present and input a Boolean > preference. > In that case, the related helper is built by the sending of > preferenceHelper to Boolean. > Another example for font, the helper is built by the sending of > preferenceHelper to LogicalFont. > > A preference helper is responsible for the input a the preference and > for the building of the textual representation > of the value which is used to code the preference method. > > alain > > StÃ©phane Ducasse a Ã©crit : >> >> On Feb 15, 2009, at 6:05 PM, Alain Plantec wrote: >> >>> StÃ©phane Ducasse a Ã©crit : >>>> Alain >>>> >>>> It would be nice to redesign completely preferences. >>> yes, it is the reason why I don't want to spend to much time on >>> the improvement of actual PreferenceBrowser. >>>> Did you read the thread >>>> Re: [Pharo-project] About Preference Flow >>>> of 4 of Feb ? >>> yes, I had it in mind. >>> Do someone know where I can find documentation on pragmas ? >> >> Pragma class je pense. >> >> Stef >> >>> >>> thanks >>> alain >>>> >>>> Summary here >>>> >>>> Instead of having the current situation ie >>>> >>>> MyTool>>doSomething >>>> >>>> .... >>>> Preferences useNewDiffTool >>>> ifTrue: [kjlhkjhjkh ] >>>> ifFalse: [nkjhkjkjhkj] >>>> >>>> >>>> and not been able to remove the preferences (or that the >>>> preference is >>>> just a configuration layer). >>>> >>>> I would like to have the preference made that way >>>> >>>> MyTool class>>useNewDiff >>>> >>>> MyTool class>> useOldDiff >>>> >>>> **NO REFERENCE TO PREFERENCE IN THE METHOD FLOW!!!! >>>> >>>> >>>> Preferences useNewDiffTool >>>> MyTool useNewDiff >>>> >>>> I like the idea of lukas to use pragmas. >>>> >>>> Why not use pragmas on accessors of the class side that would be >>>> picked up by the preference browser? Then all state would be >>>> local to >>>> the affected code. >>>> >>>> Something along these lines: >>>> >>>> MCMonticelloBrowser>>showAdvanceDiffTool: aBoolean >>>> <preference: 'Show advanced diff tool' group: 'Monticello' >>>> type: #Boolean> >>>> >>>> advancedDiffTool := aBoolean >>>> >>>> >>>>>>> Hi all, >>>>> Here is a changeset with a new version of the PreferencesBrowser. >>>>> It is for testing. I can improve it a little bit >>>>> (by including display depth, desktop color, gradient color and author >>>>> initials) >>>>> and provide a slice if it is ok. >>>>> >>>>> I've investigated how preferences are implemented and it seems to me >>>>> that >>>>> current situation is the result of succesives hacks. >>>>> I would like to clean out this part of the system. >>>>> I will provide a roadmap before any coding. >>>>> Can I start working on it ? >>>>> >>>>> Cheers >>>>> alain >>>>>>> >>>>>>>> On 11 Feb 2009, at 16:22, Alain Plantec wrote: >>>>>>>> >>>>>>>> >>>>>>>>> Hi all, >>>>>>>>> I would like to improve the PreferencesBrowser so that it >>>>>>>>> includes >>>>>>>>> standard Fonts preferences (see joined snapshot). >>>>>>>>> It's almost done except that, if a preference font is set to >>>>>>>>> Arial, >>>>>>>>> clicking on Save button leads to an infinite loop. >>>>>>>>> >>>>>>>>> To reproduce it, set button font to Arial-12 and >>>>>>>>> Preferences standardButtonFont deepCopy. >>>>>>>>> >>>>>>>>> Cheers >>>>>>>>> alain >>>>>>>>> < >>>>>>>>> FontsInPreferences >>>>>>>>> .png >>>>>>>>> >>>>>>>>>> <FTFdeepcopy.png>_______________________________________________ >>>>>>>>>> >>>>>>>>> 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 >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> <PBFont.8.cs.gz>_______________________________________________ >>>>> 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 > >

Feb. 16, 2009

Re: [Pharo-project] Preferences refactoring

by Gary Chambers

Not sure I like having the code changed all the time. If the code is changed then the MC package will show changes... The Pragma could instead specify how to set the preference (variable defined by the class/instance that declares the pragma). Regards, Gary ----- Original Message ----- From: "Alain Plantec" <beranger22(a)gmail.com> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Monday, February 16, 2009 12:25 PM Subject: Re: [Pharo-project] Preferences refactoring Here is a first proposition: preference declaration: a class method with pragma. In the image, a preference is stored as a Pragma instance (no Preference class). Actual preferences can be stored into a set of Pragma. One can use a dictionary (a class variable somewhere) in order to store several named preference set. Installing a preference set is done by the loading (code compilation) of all pragmas of the preference set. Example: AClassSomewhere>>loadPreferencesFrom: aSetOfPragma aSetOfPragma do: [:p | (p method methodReference asMethodDefinition) load] Preference method two kinds: value preference object preference - simple preference: a preference which type is a literal type examples: ChangeSet class>>checkForSlips <preferenceType: #Boolean defaultValue: true> ^ true HTTPSocket class>>httpProxyPort <preferenceType: #Integer defaultValue: 80> ^ 80 - object preference: a preference which type is any class, such a preference method return a "complex" object instance. the value is stored in a class instance variable which name is the preference name. the variable initialization is lazy. the value as well as the default value are the result of a message send to a particular class. example with font: AClassSomewhere class>>standardFont <preferenceType: #LogicalFont defaultGetter: #(#LogicalFont #familyName: 'Arial' #fallbackFamilyNames: nil #pointSize: 12 #stretchValue: 5 #weightValue: 400 #slantValue: 0)> ^ standardFont ifNil: [standardFont := LogicalFont familyName: 'Arial' fallbackFamilyNames: nil pointSize: 12 stretchValue: 5 weightValue: 400 slantValue: 0] Interoperability with file system: File in/out via standard code file, cool :) All we need is present, mainly, we have MCStWriter and MCStReader Tested example: stream := RWBinaryOrTextStream on: String new. writer := MCStWriter on: stream. "collecting and writing" PreferenceCollector allPreferencePragmas do: [ :p | (p method methodReference asMethodDefinition) accept: writer]. "reading and loading" reader := MCStReader on: stream readStream. reader definitions do: [:d | d load]. Changing a preference value: It can be simply done via code editing (no particular tool is mandatory) Helpers What we need: a cool tool to set preference values (actual PreferenceBrowser replacement) Let's call it PreferencesSetter (better name ?) PreferenceSetter needs an helper builder for each individual preference type. For a particular preference (stored as a Pragma instance), The PreferenceSetter tool ask the preference type class (found in the Pragma instance) to build the helper. as an example, we need an helper in order to present and input a Boolean preference. In that case, the related helper is built by the sending of preferenceHelper to Boolean. Another example for font, the helper is built by the sending of preferenceHelper to LogicalFont. A preference helper is responsible for the input a the preference and for the building of the textual representation of the value which is used to code the preference method. alain StÃ©phane Ducasse a Ã©crit : > > On Feb 15, 2009, at 6:05 PM, Alain Plantec wrote: > >> StÃ©phane Ducasse a Ã©crit : >>> Alain >>> >>> It would be nice to redesign completely preferences. >> yes, it is the reason why I don't want to spend to much time on >> the improvement of actual PreferenceBrowser. >>> Did you read the thread >>> Re: [Pharo-project] About Preference Flow >>> of 4 of Feb ? >> yes, I had it in mind. >> Do someone know where I can find documentation on pragmas ? > > Pragma class je pense. > > Stef > >> >> thanks >> alain >>> >>> Summary here >>> >>> Instead of having the current situation ie >>> >>> MyTool>>doSomething >>> >>> .... >>> Preferences useNewDiffTool >>> ifTrue: [kjlhkjhjkh ] >>> ifFalse: [nkjhkjkjhkj] >>> >>> >>> and not been able to remove the preferences (or that the >>> preference is >>> just a configuration layer). >>> >>> I would like to have the preference made that way >>> >>> MyTool class>>useNewDiff >>> >>> MyTool class>> useOldDiff >>> >>> **NO REFERENCE TO PREFERENCE IN THE METHOD FLOW!!!! >>> >>> >>> Preferences useNewDiffTool >>> MyTool useNewDiff >>> >>> I like the idea of lukas to use pragmas. >>> >>> Why not use pragmas on accessors of the class side that would be >>> picked up by the preference browser? Then all state would be >>> local to >>> the affected code. >>> >>> Something along these lines: >>> >>> MCMonticelloBrowser>>showAdvanceDiffTool: aBoolean >>> <preference: 'Show advanced diff tool' group: 'Monticello' >>> type: #Boolean> >>> >>> advancedDiffTool := aBoolean >>> >>> >>>>>> Hi all, >>>> Here is a changeset with a new version of the PreferencesBrowser. >>>> It is for testing. I can improve it a little bit >>>> (by including display depth, desktop color, gradient color and author >>>> initials) >>>> and provide a slice if it is ok. >>>> >>>> I've investigated how preferences are implemented and it seems to me >>>> that >>>> current situation is the result of succesives hacks. >>>> I would like to clean out this part of the system. >>>> I will provide a roadmap before any coding. >>>> Can I start working on it ? >>>> >>>> Cheers >>>> alain >>>>>> >>>>>>> On 11 Feb 2009, at 16:22, Alain Plantec wrote: >>>>>>> >>>>>>> >>>>>>>> Hi all, >>>>>>>> I would like to improve the PreferencesBrowser so that it includes >>>>>>>> standard Fonts preferences (see joined snapshot). >>>>>>>> It's almost done except that, if a preference font is set to >>>>>>>> Arial, >>>>>>>> clicking on Save button leads to an infinite loop. >>>>>>>> >>>>>>>> To reproduce it, set button font to Arial-12 and >>>>>>>> Preferences standardButtonFont deepCopy. >>>>>>>> >>>>>>>> Cheers >>>>>>>> alain >>>>>>>> < >>>>>>>> FontsInPreferences >>>>>>>> .png >>>>>>>> >>>>>>>>> <FTFdeepcopy.png>_______________________________________________ >>>>>>>>> >>>>>>>> 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 >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> <PBFont.8.cs.gz>_______________________________________________ >>>> 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

Feb. 16, 2009

Re: [Pharo-project] Preferences refactoring

by Alain Plantec

Here is a first proposition: preference declaration: a class method with pragma. In the image, a preference is stored as a Pragma instance (no Preference class). Actual preferences can be stored into a set of Pragma. One can use a dictionary (a class variable somewhere) in order to store several named preference set. Installing a preference set is done by the loading (code compilation) of all pragmas of the preference set. Example: AClassSomewhere>>loadPreferencesFrom: aSetOfPragma aSetOfPragma do: [:p | (p method methodReference asMethodDefinition) load] Preference method two kinds: value preference object preference - simple preference: a preference which type is a literal type examples: ChangeSet class>>checkForSlips <preferenceType: #Boolean defaultValue: true> ^ true HTTPSocket class>>httpProxyPort <preferenceType: #Integer defaultValue: 80> ^ 80 - object preference: a preference which type is any class, such a preference method return a "complex" object instance. the value is stored in a class instance variable which name is the preference name. the variable initialization is lazy. the value as well as the default value are the result of a message send to a particular class. example with font: AClassSomewhere class>>standardFont <preferenceType: #LogicalFont defaultGetter: #(#LogicalFont #familyName: 'Arial' #fallbackFamilyNames: nil #pointSize: 12 #stretchValue: 5 #weightValue: 400 #slantValue: 0)> ^ standardFont ifNil: [standardFont := LogicalFont familyName: 'Arial' fallbackFamilyNames: nil pointSize: 12 stretchValue: 5 weightValue: 400 slantValue: 0] Interoperability with file system: File in/out via standard code file, cool :) All we need is present, mainly, we have MCStWriter and MCStReader Tested example: stream := RWBinaryOrTextStream on: String new. writer := MCStWriter on: stream. "collecting and writing" PreferenceCollector allPreferencePragmas do: [ :p | (p method methodReference asMethodDefinition) accept: writer]. "reading and loading" reader := MCStReader on: stream readStream. reader definitions do: [:d | d load]. Changing a preference value: It can be simply done via code editing (no particular tool is mandatory) Helpers What we need: a cool tool to set preference values (actual PreferenceBrowser replacement) Let's call it PreferencesSetter (better name ?) PreferenceSetter needs an helper builder for each individual preference type. For a particular preference (stored as a Pragma instance), The PreferenceSetter tool ask the preference type class (found in the Pragma instance) to build the helper. as an example, we need an helper in order to present and input a Boolean preference. In that case, the related helper is built by the sending of preferenceHelper to Boolean. Another example for font, the helper is built by the sending of preferenceHelper to LogicalFont. A preference helper is responsible for the input a the preference and for the building of the textual representation of the value which is used to code the preference method. alain StÃ©phane Ducasse a Ã©crit : > > On Feb 15, 2009, at 6:05 PM, Alain Plantec wrote: > >> StÃ©phane Ducasse a Ã©crit : >>> Alain >>> >>> It would be nice to redesign completely preferences. >> yes, it is the reason why I don't want to spend to much time on >> the improvement of actual PreferenceBrowser. >>> Did you read the thread >>> Re: [Pharo-project] About Preference Flow >>> of 4 of Feb ? >> yes, I had it in mind. >> Do someone know where I can find documentation on pragmas ? > > Pragma class je pense. > > Stef > >> >> thanks >> alain >>> >>> Summary here >>> >>> Instead of having the current situation ie >>> >>> MyTool>>doSomething >>> >>> .... >>> Preferences useNewDiffTool >>> ifTrue: [kjlhkjhjkh ] >>> ifFalse: [nkjhkjkjhkj] >>> >>> >>> and not been able to remove the preferences (or that the >>> preference is >>> just a configuration layer). >>> >>> I would like to have the preference made that way >>> >>> MyTool class>>useNewDiff >>> >>> MyTool class>> useOldDiff >>> >>> **NO REFERENCE TO PREFERENCE IN THE METHOD FLOW!!!! >>> >>> >>> Preferences useNewDiffTool >>> MyTool useNewDiff >>> >>> I like the idea of lukas to use pragmas. >>> >>> Why not use pragmas on accessors of the class side that would be >>> picked up by the preference browser? Then all state would be >>> local to >>> the affected code. >>> >>> Something along these lines: >>> >>> MCMonticelloBrowser>>showAdvanceDiffTool: aBoolean >>> <preference: 'Show advanced diff tool' group: 'Monticello' >>> type: #Boolean> >>> >>> advancedDiffTool := aBoolean >>> >>> >>>>>> Hi all, >>>> Here is a changeset with a new version of the PreferencesBrowser. >>>> It is for testing. I can improve it a little bit >>>> (by including display depth, desktop color, gradient color and author >>>> initials) >>>> and provide a slice if it is ok. >>>> >>>> I've investigated how preferences are implemented and it seems to me >>>> that >>>> current situation is the result of succesives hacks. >>>> I would like to clean out this part of the system. >>>> I will provide a roadmap before any coding. >>>> Can I start working on it ? >>>> >>>> Cheers >>>> alain >>>>>> >>>>>>> On 11 Feb 2009, at 16:22, Alain Plantec wrote: >>>>>>> >>>>>>> >>>>>>>> Hi all, >>>>>>>> I would like to improve the PreferencesBrowser so that it includes >>>>>>>> standard Fonts preferences (see joined snapshot). >>>>>>>> It's almost done except that, if a preference font is set to >>>>>>>> Arial, >>>>>>>> clicking on Save button leads to an infinite loop. >>>>>>>> >>>>>>>> To reproduce it, set button font to Arial-12 and >>>>>>>> Preferences standardButtonFont deepCopy. >>>>>>>> >>>>>>>> Cheers >>>>>>>> alain >>>>>>>> < >>>>>>>> FontsInPreferences >>>>>>>> .png >>>>>>>> >>>>>>>>> <FTFdeepcopy.png>_______________________________________________ >>>>>>>>> >>>>>>>> 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 >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> <PBFont.8.cs.gz>_______________________________________________ >>>> 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 >> > > >

Feb. 16, 2009

Re: [Pharo-project] Loading Polymorph

by Gary Chambers

Loads from 42 upwards should be ok as normal. Polymorph-Widgets-gvc-45 now on SqueakSource with some lint related changes and a few other goodies ;-) Regards, Gary ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Sunday, February 15, 2009 2:53 PM Subject: Re: [Pharo-project] Loading Polymorph >I will try to see what I can do to load it. > > Stef > > >> Latest Polymorph-Widgets versions (from 41 to 42) require the MC >> workaround to load/merge, unfortunately. >> Anything down to drawing... in this case the change to dropShadows. >> >> Regards, Gary >> _______________________________________________ >> 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

Feb. 16, 2009

Re: [Pharo-project] unnecessary =, == :)

by Damien Cassou

On Sat, Feb 14, 2009 at 4:23 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Check for a =, ==, ~=, or ~~ message being sent to true/false or with > true/false as the argument. Many times these can be eliminated since > their receivers are already booleans. For example, "anObject isFoo == > false" could be replaced with "anObject isFoo not" if isFoo always > returns a boolean. Sometimes variables might refer to true, false, and > something else, but this is considered bad style since the variable > has multiple types. Issue #577 -- Damien Cassou http://damiencassou.seasidehosting.st

Feb. 16, 2009

Re: [Pharo-project] Sends unknown message to global

by Damien Cassou

On Sat, Feb 14, 2009 at 2:23 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > same here: would be good to define bugfix entries for each of them. Issue #576 -- Damien Cassou http://damiencassou.seasidehosting.st

Feb. 16, 2009

Re: [Pharo-project] Refers to class name instead of self class

by Damien Cassou

On Sat, Feb 14, 2009 at 4:44 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Checks for classes that have their class name directly in the source > instead of "self class". The self class variant allows you to create > subclasses without needing to redefine that method. Issue #575 -- Damien Cassou http://damiencassou.seasidehosting.st

Feb. 16, 2009

Re: [Pharo-project] undeclared variables

by Damien Cassou

On Sat, Feb 14, 2009 at 2:16 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > It would be good to fix such problems in their respective packages. Issue #574 -- Damien Cassou http://damiencassou.seasidehosting.st

Feb. 16, 2009

Re: [Pharo-project] methods equivalently defined in superclass

by Damien Cassou

On Sat, Feb 14, 2009 at 4:20 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > I imagine that we could fix that too :) Issue #573 -- Damien Cassou http://damiencassou.seasidehosting.st

Feb. 16, 2009