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" <[email protected]>
> To: <[email protected]>
> 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
>>>>>>>>> [email protected]
>>>>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Pharo-project mailing list
>>>>>>> [email protected]
>>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> <PBFont.8.cs.gz>_______________________________________________
>>>>> Pharo-project mailing list
>>>>> [email protected]
>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>
>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [email protected]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>
>>
>>
>
>
> _______________________________________________
> Pharo-project mailing list
> [email protected]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
