LogicalFont deepCopy infinite loop with Arial font

> 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. :)
>>
>>
> .....
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> 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]

> 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
> [hidden email]
> 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

>
> 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]

> 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'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

>
> 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]

> 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.

> 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" <[hidden email]>
> To: <[hidden email]>
> 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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
> Regards, Gary
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>