LogicalFont deepCopy infinite loop with Arial font

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
29 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Preferences refactoring

Gary Chambers-4
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" <[hidden email]>
To: <[hidden email]>
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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
>


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project 


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Preferences refactoring

Michael Rueger-6
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
Reply | Threaded
Open this post in threaded view
|

Re: Preferences refactoring

Gary Chambers-4
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" <[hidden email]>
To: <[hidden email]>
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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project 


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Preferences refactoring

Alain Plantec-2
In reply to this post by Gary Chambers-4
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
Reply | Threaded
Open this post in threaded view
|

Re: Preferences refactoring

Alain Plantec-2
In reply to this post by Michael Rueger-6
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
>
>


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Preferences refactoring

Gary Chambers-4
In reply to this post by Alain Plantec-2
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
Reply | Threaded
Open this post in threaded view
|

Re: Preferences refactoring

Tapple Gao
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/

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Preferences refactoring

Tapple Gao
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/

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Reply | Threaded
Open this post in threaded view
|

Re: Preferences refactoring

Stéphane Ducasse
In reply to this post by Gary Chambers-4
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" <[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
>


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
12