[Pharo-project] LogicalFont deepCopy infinite loop with Arial font
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
Go go Alain! This is great! Alexandre 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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Alexandre Bergel a écrit :
Go go Alain! This is great!
Alexandre Thank, I'm sure that you are tired of having to set
fonts each time you take a fresh image :)
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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Thank, I'm sure that you are tired of having to set
fonts each time you take a fresh image :)
More than this :-) "tired" is a weak word... Alexandre
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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Alexandre Bergel a écrit :
Thank, I'm sure that you are tired of having to set
fonts each time you take a fresh image :)
More than this :-) "tired" is a weak word...
Alexandre
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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Alain It would be nice to redesign completely preferences. Did you read the thread Re: [Pharo-project] About Preference Flow of 4 of Feb ? 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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- project
_______________________________________________ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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 ? 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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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@gmail.com> To: <Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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@gmail.com> To: <Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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. :)
.....
Alain Plantec a écrit :
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
ok one can have: XX class>>myPreference: aValue "self myPreference: myValue" myPreference := aValue and the user edits the comment of the setter and evaluates it without saving the code. Cheers 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. :)
.....
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I'll have a think. Some theme settings can currently be set (manually) on a per theme basis. Would be nice to handle that, though the pragma route suggests that a static facade would be needed to delegate to the defaults for the current theme... I'd see something like X class>>myPreference <preference: 'Readable name' type: #Boolean set: #myPreference: default: #defaultMyPreference description: 'Helpful text'> ^ myPreference ifNil: [myPreference := self defaultMyPreference] X class>>defaultMyPreference ^false X class>>myPreference: aTValue myPreference := aTValue. "do any stuff to notify/apply change..." That would be enough got get the value (selector of pragma) and all the rest. The default value needs to be by method since pragma arguents only support literals (some preferences may be complex objects). The type can be used by the preference browser to determine how to handle the values... I suggest having the class name of the expected value here to help with that (the class may have extensions allowing it to work with the preference browser). Of course, another approach is to just decentralize the preferences... X class>>xyzColorPreference <preference> ^Preference new name: #xyzColor defaultValue: Color red helpString: 'Specifies the xyz color of abc' localToProject: false categoryList: #(#'window colors') changeInformee: self changeSelector: #xyzColor: viewRegistry: (PreferenceViewRegistry registryOf: #windowColorPreferences) And tweak Preference>>notifyInformeeOfChange to handle the argument for the changeSelector (passing the new preference value). That should work ok with the existing preference browser with a few tweaks (the preference browser should have a its preferences var set to a new instance of a class that provides the relevant protocol that is used on the Preference class side but with the preferences discovered via the code below). (Object withAllSubclasses inject: OrderedCollection new into: [:pragmas :class | pragmas, (Pragma allNamed: #preference in: class)]) collect: [:pragma | pragma methodClass theNonMetaClass perform: pragma selector] This means that we can retain the categorisation of preferences and existing editing machinery etc. All pretty hideous, one way or another... Regards, Gary ----- Original Message ----- From: "Alain Plantec" <beranger22@gmail.com> To: <Pharo-project@lists.gforge.inria.fr> Sent: Monday, February 16, 2009 2:15 PM Subject: Re: [Pharo-project] Preferences refactoring Alain Plantec a écrit :
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
ok one can have: XX class>>myPreference: aValue "self myPreference: myValue" myPreference := aValue and the user edits the comment of the setter and evaluates it without saving the code. Cheers 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. :)
.....
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Gary Chambers wrote:
I'll have a think. Some theme settings can currently be set (manually) on a per theme basis. Would be nice to handle that, though the pragma route suggests that a static facade would be needed to delegate to the defaults for the current theme...
I'd see something like
X class>>myPreference <preference: 'Readable name' type: #Boolean set: #myPreference: default: #defaultMyPreference description: 'Helpful text'> ^ myPreference ifNil: [myPreference := self defaultMyPreference]
In Sophie we have a Preference system supporting user and system level preferences as well as preference definitions similar to the one above. In my ySqueak experiments I extended that so classes can register as "preference provider" and also as listeners to preference changes. Michael
Fair. I guess a simplified version of the announcement pattern could be used for notification. Of course, to avoid repeating code one might want a Preferences instance (not like the current Preferences class stuff) that can be registered with for those classses supporting preferences. E.g. for a subscriber: XYZClass preferences observe: #windowColor do: [:pref | ...] And for a preferences supplier you might have the Preferences instance referenced by a class var or something. Regards, Gary ----- Original Message ----- From: "Michael Rueger" <m.rueger@acm.org> To: <Pharo-project@lists.gforge.inria.fr> Sent: Monday, February 16, 2009 3:50 PM Subject: Re: [Pharo-project] Preferences refactoring
Gary Chambers wrote:
I'll have a think. Some theme settings can currently be set (manually) on a per theme basis. Would be nice to handle that, though the pragma route suggests that a static facade would be needed to delegate to the defaults for the current theme...
I'd see something like
X class>>myPreference <preference: 'Readable name' type: #Boolean set: #myPreference: default: #defaultMyPreference description: 'Helpful text'> ^ myPreference ifNil: [myPreference := self defaultMyPreference]
In Sophie we have a Preference system supporting user and system level preferences as well as preference definitions similar to the one above.
In my ySqueak experiments I extended that so classes can register as "preference provider" and also as listeners to preference changes.
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Michael Rueger a écrit :
Gary Chambers wrote:
I'll have a think. Some theme settings can currently be set (manually) on a per theme basis. Would be nice to handle that, though the pragma route suggests that a static facade would be needed to delegate to the defaults for the current theme...
I'd see something like
X class>>myPreference <preference: 'Readable name' type: #Boolean set: #myPreference: default: #defaultMyPreference description: 'Helpful text'> ^ myPreference ifNil: [myPreference := self defaultMyPreference]
In Sophie we have a Preference system supporting user and system level preferences as well as preference definitions similar to the one above.
In my ySqueak experiments I extended that so classes can register as "preference provider" and also as listeners to preference changes. I like Announcement :) alain
Michael
Gary Chambers a écrit :
I'll have a think. Some theme settings can currently be set (manually) on a per theme basis. Would be nice to handle that, though the pragma route suggests that a static facade would be needed to delegate to the defaults for the current theme...
I'd see something like
X class>>myPreference <preference: 'Readable name' type: #Boolean set: #myPreference: default: #defaultMyPreference description: 'Helpful text'> ^ myPreference ifNil: [myPreference := self defaultMyPreference]
X class>>defaultMyPreference ^false
X class>>myPreference: aTValue myPreference := aTValue. "do any stuff to notify/apply change..."
That would be enough got get the value (selector of pragma) and all the rest. The default value needs to be by method since pragma arguents only support literals (some preferences may be complex objects). The type can be used by the preference browser to determine how to handle the values... I suggest having the class name of the expected value here to help with that ok, this is what I suggested also (all informations are explicitly declared with pragma)
(the class may have extensions allowing it to work with the preference browser). i'm not sure it is a good idea to keep the current preference browser ...
Of course, another approach is to just decentralize the preferences...
X class>>xyzColorPreference <preference> ^Preference new name: #xyzColor defaultValue: Color red helpString: 'Specifies the xyz color of abc' localToProject: false categoryList: #(#'window colors') changeInformee: self changeSelector: #xyzColor: viewRegistry: (PreferenceViewRegistry registryOf: #windowColorPreferences)
And tweak Preference>>notifyInformeeOfChange to handle the argument for the changeSelector (passing the new preference value). * I prefer previous solution. Maybe we need a Preference class but I'm not sure.
That should work ok with the existing preference browser with a few tweaks (the preference browser should have a its preferences var set to a new instance of a class that provides the relevant protocol that is used on the Preference class side but with the preferences discovered via the code below).
(Object withAllSubclasses inject: OrderedCollection new into: [:pragmas :class | pragmas, (Pragma allNamed: #preference in: class)]) collect: [:pragma | pragma methodClass theNonMetaClass perform: pragma selector] yes, cool code :)
alain
So, for new browser it needs to be decided what information to show as this will affect the pragma. For instance, do we still want categories, "project specific" (probably not) etc. I expect we will want a Preference class either way to model each preference in the browser. Making a new browser is quite an undertaking given the different types of preference (boolean, text, one-of-many, colour, font etc.). Regards, Gary. ----- Original Message ----- From: "Alain Plantec" <beranger22@gmail.com> To: <Pharo-project@lists.gforge.inria.fr> Sent: Monday, February 16, 2009 5:08 PM Subject: Re: [Pharo-project] Preferences refactoring Gary Chambers a écrit :
I'll have a think. Some theme settings can currently be set (manually) on a per theme basis. Would be nice to handle that, though the pragma route suggests that a static facade would be needed to delegate to the defaults for the current theme...
I'd see something like
X class>>myPreference <preference: 'Readable name' type: #Boolean set: #myPreference: default: #defaultMyPreference description: 'Helpful text'> ^ myPreference ifNil: [myPreference := self defaultMyPreference]
X class>>defaultMyPreference ^false
X class>>myPreference: aTValue myPreference := aTValue. "do any stuff to notify/apply change..."
That would be enough got get the value (selector of pragma) and all the rest. The default value needs to be by method since pragma arguents only support literals (some preferences may be complex objects). The type can be used by the preference browser to determine how to handle the values... I suggest having the class name of the expected value here to help with that ok, this is what I suggested also (all informations are explicitly declared with pragma)
(the class may have extensions allowing it to work with the preference browser). i'm not sure it is a good idea to keep the current preference browser ...
Of course, another approach is to just decentralize the preferences...
X class>>xyzColorPreference <preference> ^Preference new name: #xyzColor defaultValue: Color red helpString: 'Specifies the xyz color of abc' localToProject: false categoryList: #(#'window colors') changeInformee: self changeSelector: #xyzColor: viewRegistry: (PreferenceViewRegistry registryOf: #windowColorPreferences)
And tweak Preference>>notifyInformeeOfChange to handle the argument for the changeSelector (passing the new preference value). * I prefer previous solution. Maybe we need a Preference class but I'm not sure.
That should work ok with the existing preference browser with a few tweaks (the preference browser should have a its preferences var set to a new instance of a class that provides the relevant protocol that is used on the Preference class side but with the preferences discovered via the code below).
(Object withAllSubclasses inject: OrderedCollection new into: [:pragmas :class | pragmas, (Pragma allNamed: #preference in: class)]) collect: [:pragma | pragma methodClass theNonMetaClass perform: pragma selector] yes, cool code :)
alain _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project Regards, Gary
On Mon, Feb 16, 2009 at 05:32:33PM -0000, Gary Chambers wrote:
So, for new browser it needs to be decided what information to show as this will affect the pragma. For instance, do we still want categories, "project specific" (probably not) etc.
I expect we will want a Preference class either way to model each preference in the browser. Making a new browser is quite an undertaking given the different types of preference (boolean, text, one-of-many, colour, font etc.).
I think Magritte is the proper solution. It already handles UI metadata like this. Regarding preferences being optional, I think just a few tweaks to the MC loader would work: If the Preferences Browser is not loaded, MC will not compile the methods that return the Magritte metadata. If this is done properly, as in MC1.5, these methods will hang out uncompiled in the orphanage until you load the preferences package, at which point they will be loaded into the image. Out-of-order package loading is nice. -- Matthew Fulmer -- http://mtfulmer.wordpress.com/
On Mon, Feb 16, 2009 at 02:19:55PM -0500, Matthew Fulmer wrote:
On Mon, Feb 16, 2009 at 05:32:33PM -0000, Gary Chambers wrote:
So, for new browser it needs to be decided what information to show as this will affect the pragma. For instance, do we still want categories, "project specific" (probably not) etc.
I expect we will want a Preference class either way to model each preference in the browser. Making a new browser is quite an undertaking given the different types of preference (boolean, text, one-of-many, colour, font etc.).
I think Magritte is the proper solution. It already handles UI metadata like this.
Something like this: prefTheme <preference category: 'User Interface'> ^ MASingleOptionDescription new options: #( 'Vistary' 'Watery' 'Squeak' 'Soft Squeak' ); reference: MAStringDescription new; autoAccessor: 'theme'; label: 'Theme'; priority: 40; beSorted; yourself
Regarding preferences being optional, I think just a few tweaks to the MC loader would work: If the Preferences Browser is not loaded, MC will not compile the methods that return the Magritte metadata. If this is done properly, as in MC1.5, these methods will hang out uncompiled in the orphanage until you load the preferences package, at which point they will be loaded into the image.
This is completely wrong. In the above example, if Magritte was not loaded, MASingleOptionDescription will bind to Undeclared. Then, if Magritte is ever loaded, it will notice the reference in Undeclared, and recompile this method to act correctly.
Out-of-order package loading is nice.
Out-of-order loading, in the form of global references, has been supported since smalltalk-76 by the Undeclared object. The MC1.5 orphanage supports another kind of out-of-order loading, in addition to that supported by Undeclared. But it is irrelavant in this example. -- Matthew Fulmer -- http://mtfulmer.wordpress.com/
I did not follow in detail but my gut feeling is the following one: - keep the preference browser as a layer on top of the rest - change the preferences default and move them into the tools (pragmas there). - change the flow to not query the preference class during the execution of the tools. I will try to get back my brain to read the thread. stef On Feb 16, 2009, at 6:32 PM, Gary Chambers wrote:
So, for new browser it needs to be decided what information to show as this will affect the pragma. For instance, do we still want categories, "project specific" (probably not) etc.
I expect we will want a Preference class either way to model each preference in the browser. Making a new browser is quite an undertaking given the different types of preference (boolean, text, one-of-many, colour, font etc.).
Regards, Gary.
----- Original Message ----- From: "Alain Plantec" <beranger22@gmail.com> To: <Pharo-project@lists.gforge.inria.fr> Sent: Monday, February 16, 2009 5:08 PM Subject: Re: [Pharo-project] Preferences refactoring
Gary Chambers a écrit :
I'll have a think. Some theme settings can currently be set (manually) on a per theme basis. Would be nice to handle that, though the pragma route suggests that a static facade would be needed to delegate to the defaults for the current theme...
I'd see something like
X class>>myPreference <preference: 'Readable name' type: #Boolean set: #myPreference: default: #defaultMyPreference description: 'Helpful text'> ^ myPreference ifNil: [myPreference := self defaultMyPreference]
X class>>defaultMyPreference ^false
X class>>myPreference: aTValue myPreference := aTValue. "do any stuff to notify/apply change..."
That would be enough got get the value (selector of pragma) and all the rest. The default value needs to be by method since pragma arguents only support literals (some preferences may be complex objects). The type can be used by the preference browser to determine how to handle the values... I suggest having the class name of the expected value here to help with that ok, this is what I suggested also (all informations are explicitly declared with pragma)
(the class may have extensions allowing it to work with the preference browser). i'm not sure it is a good idea to keep the current preference browser ...
Of course, another approach is to just decentralize the preferences...
X class>>xyzColorPreference <preference> ^Preference new name: #xyzColor defaultValue: Color red helpString: 'Specifies the xyz color of abc' localToProject: false categoryList: #(#'window colors') changeInformee: self changeSelector: #xyzColor: viewRegistry: (PreferenceViewRegistry registryOf: #windowColorPreferences)
And tweak Preference>>notifyInformeeOfChange to handle the argument for the changeSelector (passing the new preference value). * I prefer previous solution. Maybe we need a Preference class but I'm not sure.
That should work ok with the existing preference browser with a few tweaks (the preference browser should have a its preferences var set to a new instance of a class that provides the relevant protocol that is used on the Preference class side but with the preferences discovered via the code below).
(Object withAllSubclasses inject: OrderedCollection new into: [:pragmas :class | pragmas, (Pragma allNamed: #preference in: class)]) collect: [:pragma | pragma methodClass theNonMetaClass perform: pragma selector] yes, cool code :)
alain
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Regards, Gary
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Sun, Feb 15, 2009 at 03:47:27PM +0100, St?phane Ducasse wrote:
Alain
It would be nice to redesign completely preferences. Did you read the thread Re: [Pharo-project] About Preference Flow of 4 of Feb ?
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
One issue with this is that, from what I can tell, it does not permit you to save preferences outside the image. I think it would be really great if my preferences for Polymorph theme and fonts and browser look and feel would be read from a standard place and applied whenever I loaded up the latest Pharo image. I don't see a way to have that and also make Preferences optional. -- Matthew Fulmer -- http://mtfulmer.wordpress.com/
On Sun, Feb 15, 2009 at 06:39:46PM -0500, Matthew Fulmer wrote:
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
One issue with this is that, from what I can tell, it does not permit you to save preferences outside the image. I think it would be really great if my preferences for Polymorph theme and fonts and browser look and feel would be read from a standard place and applied whenever I loaded up the latest Pharo image. I don't see a way to have that and also make Preferences optional.
uh, nevermind. this could be done just as easily as it could be using the current design of preferences. Sorry for the noise. Take this as a feature request for the new and improved Preferences system! By the way, I love what you guys are doing with Pharo. I'm sorry I can't spend my time helping you guys yet. I hope Pharo becomes the default Squeak in the future. -- Matthew Fulmer -- http://mtfulmer.wordpress.com/
uh, nevermind. this could be done just as easily as it could be using the current design of preferences. Sorry for the noise.
ok no problem :)
Take this as a feature request for the new and improved Preferences system!
By the way, I love what you guys are doing with Pharo. I'm sorry I can't spend my time helping you guys yet. I hope Pharo becomes the default Squeak in the future.
make a great master and after apply to our INRIA PhD proposal :)
-- Matthew Fulmer -- http://mtfulmer.wordpress.com/
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Why you could not save the selector you should send to your components.... A layer on top does not imply that component should call you but after you can do what you want to represent load and save data. So your remark is wrong. Stef
It would be nice to redesign completely preferences. Did you read the thread Re: [Pharo-project] About Preference Flow of 4 of Feb ?
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
One issue with this is that, from what I can tell, it does not permit you to save preferences outside the image. I think it would be really great if my preferences for Polymorph theme and fonts and browser look and feel would be read from a standard place and applied whenever I loaded up the latest Pharo image. I don't see a way to have that and also make Preferences optional.
-- Matthew Fulmer -- http://mtfulmer.wordpress.com/
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Saved preferences seems broken in other ways... it seems to lead to odd obsoletions of the PBPreferenceView subclasses... probably due to the deepcopy. I'm not sure deep copying is really wanted here, there's probably a better way. Regards, Gary ----- Original Message ----- From: "Alain Plantec" <alain.plantec@free.fr> To: <Pharo-project@lists.gforge.inria.fr> Sent: Wednesday, February 11, 2009 3:22 PM Subject: [Pharo-project] LogicalFont deepCopy infinite loop with Arial font
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
--------------------------------------------------------------------------------
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Gary Chambers a écrit :
Saved preferences seems broken in other ways... it seems to lead to odd obsoletions of the PBPreferenceView subclasses... probably due to the deepcopy. I'm not sure deep copying is really wanted here, there's probably a better way. ok, I will try to repare and improve it. alain
Regards, Gary
----- Original Message ----- From: "Alain Plantec" <alain.plantec@free.fr> To: <Pharo-project@lists.gforge.inria.fr> Sent: Wednesday, February 11, 2009 3:22 PM Subject: [Pharo-project] LogicalFont deepCopy infinite loop with Arial font
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
--------------------------------------------------------------------------------
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Good luck! Regards, Gary ----- Original Message ----- From: "Alain Plantec" <alain.plantec@free.fr> To: <Pharo-project@lists.gforge.inria.fr> Sent: Wednesday, February 11, 2009 5:02 PM Subject: Re: [Pharo-project] LogicalFont deepCopy infinite loop with Arial font Gary Chambers a écrit :
Saved preferences seems broken in other ways... it seems to lead to odd obsoletions of the PBPreferenceView subclasses... probably due to the deepcopy. I'm not sure deep copying is really wanted here, there's probably a better way. ok, I will try to repare and improve it. alain
Regards, Gary
----- Original Message ----- From: "Alain Plantec" <alain.plantec@free.fr> To: <Pharo-project@lists.gforge.inria.fr> Sent: Wednesday, February 11, 2009 3:22 PM Subject: [Pharo-project] LogicalFont deepCopy infinite loop with Arial font
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
--------------------------------------------------------------------------------
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (7)
-
Alain Plantec -
Alain Plantec -
Alexandre Bergel -
Gary Chambers -
Matthew Fulmer -
Michael Rueger -
Stéphane Ducasse