[Fwd: Re: [ANN] Preference pragmas]

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

[Fwd: Re: [ANN] Preference pragmas]

Alain Plantec-4
and here is my answer.
Cheers
Alain

Hi Andreas,

Andreas Raab a écrit :
> Alain's implementation of preferences is an improvement on the current
> preference system but it is effectively replacing one set of
> dependencies with a different set of dependencies. Where previously
> Preferences would be registered and stored via Preferences
> addPreference:... in Alain's approach preferences get created via (the
> old version):
...

> or, with the latest:
>
> gradientButtonLook
>     <preference>
>     ^ GradientButtonLook
>         ifNil: [GradientButtonLook := PreferenceValue
>                         name: 'Gradient look for buttons'
>                         description: 'Gradient look for buttons'
>                         parent: #uiPreferenceNode
>                         type: #Boolean
>                         default: false]
>
> In other words, a dependency (to either PreferenceNode,
> PreferenceValue, RangePreferenceValue, MultiplePreferenceValue etc) is
> created and stored client-side.
With Pharo approach, your code depends on a unique small hierarchy of
classes exactly as it can depend on Collection one.
It does not depend on a global object (Preferences) as it is now.
For me, it is not a problem since preferences are declared locally in
packages (exactly as in your pragma approach)
>
> My approach differs in such that it is aimed at being discoverable
> without introducing any dependencies.
I don't think so, you are introducing a dependency on a particular
syntax wich is <preference: something: somethingelse: >
I think it is better to rely on classes and not to depend on a flat syntax.

> defaultPollPeriod
>     "Answer the number of milliseconds between interrupts for spyOn:
> and friends.
>     This should be faster for faster machines."
>     <preference: 'Default Poll Period'
>         category: 'Profiling'
>         description: 'The default poll period (msecs) MessageTally uses'
>         type: #Number>
>     ^DefaultPollPeriod ifNil: [ DefaultPollPeriod _ 1 ]
>
You also need
defaultPollPeriod: aNumber
    DefaultPollPeriod := aNumber

and maybe another method for the default and maybe something else for
system level notification.

Only a detail maybe but In our implementation, for one preference, you
need to set only one declaration:
and you use the preference like this:
v := UIPreferences gradientButtonLook value.
UIPreferences gradientButtonLook value: false.

It allows  system level notification because #PreferenceValue>>value:
triggers a #PreferenceChanged events.
An  object can be declared as listener to a particular preference value
like this:
MyObject>>initialize
    super initialize.
    UIPreferences gradientButtonLook whenChangedSend:
#gradientButtonLookIsNow: to: self.

the opposite is #forget:
MyObject>>release
    UIPreferences gradientButtonLook forget: self

You can see it as a replacement for changeInformee: informeeSymbol  
changeSelector: aChangeSelector.

> However, since this was discovered via pragmas, no dependency between
> Preferences and MessageTally has been created.
again, the dependency is on the syntax of the pragma
> You can remove or replace the preferences implementation in the image
> without any side effects whatsoever on MessageTally or its code. A
> different preference implementation can discover the same preference
> and present it accordingly. This allows adding preferences wherever is
> convenient without needlessly introducing dependencies on a particular
> preference implementation or UI.
Pharo preference do not depends on a particular UI. PreferenceSupport is
removeable without any side effect on the system.
But I agree that it depends on the PreferenceNode hierarchy.
>
>
> In Alain's version this would not be possible without actually
> changing code since it is directly coupled to a particular preference
> class and API.
ok but the pragma-only declaration is poor: only flat syntax which
allows only literals as parameters.
the consequence is that you can't deal with one-to-many or range
preference or something else you can discover later.
Two examples:
here the value domain is explicitly given with the help of a
MultiplePreferenceValue. Each possible value of the preference is given
with FixedPreferenceValue instances.
themePreference
    <preference>
    ^ ThemePreference
        ifNil: [ThemePreference := MultiplePreferenceValue
                        name: 'UITheme'
                        description: 'The theme to use for UI look and feel'
                        parent: #uiPreferenceNode      
                        type: #UITheme  
                        default: UIThemeWatery2
                        values: {
                            FixedPreferenceValue
                                name: 'Standard Squeak'
                                description: 'Standard Squeak style'
                                type: #UITheme                        
       
                                value: UIThemeStandardSqueak.
                            FixedPreferenceValue
                                name: 'Watery 2'
                                description: 'Similar to a nice OS'
                                type: #UITheme
                                value: UIThemeWatery2}]

here a range preference value, again, the value domain is explicitly given.
glyphContrast
    <preference>
    ^ GlyphContrast
        ifNil: [GlyphContrast := RangePreferenceValue
                        name: 'Glyph contrast'
                        description: 'Change the contrast level for
glyphs. This is an integer between 1 and 100. (the default value is 50)'
                        parent:  #freeTypePreferenceNode
                        type: #Integer
                        default: 50
                        range: (1 to: 100)]

If you only make use of a poor preference declaration (I consider
preference pragma flat declaration as a poor flat textual declaration)
it can have bad effects on the quality of the code which is using
the preference.
See how freetype hinting preference are currently handled.
You have 4 boolean preferences wheras following declaration better fits:

hintingPreference
    <preference>
    ^ HintingPreference
        ifNil: [HintingPreference := MultiplePreferenceValue
                        name: 'Hinting'
                        description: 'Changes the glyph shapes'
                        parent: #freeTypePreferenceNode      
                        type: #Symbol  
                        default: #Light
                        values: {
                            FixedPreferenceValue
                                name: 'Light'
                                description: 'Light hinting, bla bla bla
....'
                                type: #Symbol                            
   
                                value: #Light.
                            FixedPreferenceValue
                                name: 'Full'
                                description: 'Full hinting bla bla bla ....'
                                type: #Symbol
                                value: #Full.
                            FixedPreferenceValue
                                name: 'None'
                                description: 'None hinting bla bla bla ....'
                                type: #Symbol                            
   
                                value: #None.
                            FixedPreferenceValue
                                name: 'Normal'
                                description: 'Normal hinting bla bla bla
....'
                                type: #Symbol
                                value: #Normal}]

FixedPreferenceValue instance can be also bound to more complex values
than simple symbol (#Light, #Full ...)
            FixedPreferenceValue
                                name: 'Light'
                                description: 'Light hinting, bla bla bla
....'
                                type: #FreeTypeHinting                
             
                                value: [FreeTypeLightHinting new].
or
            FixedPreferenceValue
                                name: 'Light'
                                description: 'Light hinting, bla bla bla
....'
                                type: #FreeTypeHinting                
             
                                value: (MessageSend receiver:
FreeTypeLightHinting selector: #new).


Thus, the declaration is more rich. As a consequence, also with the help
of the system level notification,
a client code can be much more simple and well designed.
I mean avoiding code like:

FreeTypeSettings>>hintingFullPreferenceChanged
    Preferences HintingFull
        ifTrue:[Preferences disable: #HintingNone; disable:
#HintingLight; disable: #HintingNormal]
        ifFalse:[
            (Preferences HintingNone or:[Preferences HintingLight
or:[Preferences HintingNormal]])
                ifFalse:[
                    "turn it back on again"
                    ^Preferences enable: #HintingFull]].
    monoHinting := Preferences HintingFull.
    lightHinting := Preferences HintingLight.
    hinting := monoHinting or:[lightHinting or:[Preferences HintingNormal]].
    FreeTypeCache current removeAll.
    FreeTypeFont allSubInstances do:[:each | each clearCachedMetrics].
    NewParagraph allSubInstances do:[:each | each composeAll].
    World restoreMorphicDisplay.

The last point you maybe missed (which is maybe not so important) is
that what we are declaring is a tree of preferences.
See Snapshot attached (For now, only a poor tool version,
"PreferenceTree open" to see it in action), it  ilustrates well the point.
An again, this kind of tool is NOT mandatory. Related package can be
removed without side effect on the system because
it also makes use of dynamic preference discovering with the help of Pragma.

ah, the real last point is the default value: in your point of view,
default values depend on value type.
I can't agree with that point of view. It would mean, as an example,
that every boolean preferences have false, or true as the default.
The problem with non-literals then arises if you want to declare default
value with pragma...

ah, again. If your system relies on a <preference:truc:...> syntax. What
about evolution of the system ?
If you want to change all  declarations, you have to find them all. As
far as I know, you can't rely on standard code browser for it.
And what about external tools and user application ?

Gary Chambers quote: -------------------------
> The simple pragma approach I described would make it easier for the
> tools though since they wouldn't need a separate model (or hang onto
> the pragma) in order to work.
>
> Also, for user applications. Our ReportBuilder, for instance, also has
> an end-user ui for preferences local to itself. Having acccess to the
> default value/description withough having to find the pragma would be
> easier. (Just an example, the ReportBuilder actually uses xml config
> files for its prefs).
------------------------- End of Gary quote
>
> Bottom line: I think my approach is a necessity before Alain's
> preference implementation can be usefully deployed. It allows us to
> define preferences without introducing dependencies to specific
> implementations, while allowing different implementations to discover
> the same preferences.
I do not really understand.
>
> I hope this makes the conceptual difference clear.
Thanks for it.
...and remarks, critics, idea, improvements are welcomed.

Cheers
alain
>
> Cheers,
>   - Andreas
>
>
>


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

Preference tree.png (57K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Fwd: Re: [ANN] Preference pragmas]

Tapple Gao
On Fri, Mar 06, 2009 at 10:36:13AM +0100, Alain Plantec wrote:

> themePreference
>     <preference>
>     ^ ThemePreference
>         ifNil: [ThemePreference := MultiplePreferenceValue
>                         name: 'UITheme'
>                         description: 'The theme to use for UI look and feel'
>                         parent: #uiPreferenceNode      
>                         type: #UITheme  
>                         default: UIThemeWatery2
>                         values: {
>                             FixedPreferenceValue
>                                 name: 'Standard Squeak'
>                                 description: 'Standard Squeak style'
>                                 type: #UITheme                        
>        
>                                 value: UIThemeStandardSqueak.
>                             FixedPreferenceValue
>                                 name: 'Watery 2'
>                                 description: 'Similar to a nice OS'
>                                 type: #UITheme
>                                 value: UIThemeWatery2}]

You're really just inventing a half-baked Magritte now. Do
yourself a favor and use the real thing. Magritte is far more
descriptive and far less verbose than anything you have yet
presented. Magritte also already knows how to automatically create both
seaside and morphic forms out of a field description. It also
knows more ways to look up a field than just selector and block.

--
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: [Fwd: Re: [ANN] Preference pragmas]

NorbertHartl
On Fri, 2009-03-06 at 05:20 -0500, Matthew Fulmer wrote:

> On Fri, Mar 06, 2009 at 10:36:13AM +0100, Alain Plantec wrote:
> > themePreference
> >     <preference>
> >     ^ ThemePreference
> >         ifNil: [ThemePreference := MultiplePreferenceValue
> >                         name: 'UITheme'
> >                         description: 'The theme to use for UI look and feel'
> >                         parent: #uiPreferenceNode      
> >                         type: #UITheme  
> >                         default: UIThemeWatery2
> >                         values: {
> >                             FixedPreferenceValue
> >                                 name: 'Standard Squeak'
> >                                 description: 'Standard Squeak style'
> >                                 type: #UITheme                        
> >        
> >                                 value: UIThemeStandardSqueak.
> >                             FixedPreferenceValue
> >                                 name: 'Watery 2'
> >                                 description: 'Similar to a nice OS'
> >                                 type: #UITheme
> >                                 value: UIThemeWatery2}]
>
> You're really just inventing a half-baked Magritte now. Do
> yourself a favor and use the real thing. Magritte is far more
> descriptive and far less verbose than anything you have yet
> presented. Magritte also already knows how to automatically create both
> seaside and morphic forms out of a field description. It also
> knows more ways to look up a field than just selector and block.
>
I don't think so. This is a definition of composite value model. The
value model does not need to reflect the structure of the objects
that use those preferences. Magritte on the other side would describe
the other model as it is a meta-model description. And Magritte is a
lot more heavy weight. So while it looks similar I can't see what you
are telling.
But you could use Magritte to describe this model ad then generate
a UI out of it ;)

Norbert



_______________________________________________
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: [Fwd: Re: [ANN] Preference pragmas]

Alain Plantec-4
In reply to this post by Tapple Gao
Matthew Fulmer a écrit :

> On Fri, Mar 06, 2009 at 10:36:13AM +0100, Alain Plantec wrote:
>  
>> themePreference
>>     <preference>
>>     ^ ThemePreference
>>         ifNil: [ThemePreference := MultiplePreferenceValue
>>                         name: 'UITheme'
>>                         description: 'The theme to use for UI look and feel'
>>                         parent: #uiPreferenceNode      
>>                         type: #UITheme  
>>                         default: UIThemeWatery2
>>                         values: {
>>                             FixedPreferenceValue
>>                                 name: 'Standard Squeak'
>>                                 description: 'Standard Squeak style'
>>                                 type: #UITheme                        
>>        
>>                                 value: UIThemeStandardSqueak.
>>                             FixedPreferenceValue
>>                                 name: 'Watery 2'
>>                                 description: 'Similar to a nice OS'
>>                                 type: #UITheme
>>                                 value: UIThemeWatery2}]
>>    
>
>  
Hi Matthew,
> You're really just inventing a half-baked Magritte now.
Surely, but, for now, Magritte is not in the base system.
Maybe you can send some advices or ideas about how we can improve
the preference system.

And the <preference:ziag:zig:> way is still a solution we can adopt back
if the pharo community prefers it.

> Do
> yourself a favor and use the real thing. Magritte is far more
> descriptive and far less verbose than anything you have yet
> presented. Magritte also already knows how to automatically create both
> seaside and morphic forms out of a field description. It also
> knows more ways to look up a field than just selector and block.
>  
Anyway, it seems very interesting and I would like to learn a bit about
Magritte even it is not possible to use it for preferences.
As an example, could you explain how you specify the themePreference
with Magritte ?
Maybe it can help us to improve our implementation.
Thanks
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: [Fwd: Re: [ANN] Preference pragmas]

NorbertHartl
On Fri, 2009-03-06 at 12:02 +0100, Alain Plantec wrote:

> Matthew Fulmer a écrit :
> > On Fri, Mar 06, 2009 at 10:36:13AM +0100, Alain Plantec wrote:
> >  
> >> themePreference
> >>     <preference>
> >>     ^ ThemePreference
> >>         ifNil: [ThemePreference := MultiplePreferenceValue
> >>                         name: 'UITheme'
> >>                         description: 'The theme to use for UI look and feel'
> >>                         parent: #uiPreferenceNode      
> >>                         type: #UITheme  
> >>                         default: UIThemeWatery2
> >>                         values: {
> >>                             FixedPreferenceValue
> >>                                 name: 'Standard Squeak'
> >>                                 description: 'Standard Squeak style'
> >>                                 type: #UITheme                        
> >>        
> >>                                 value: UIThemeStandardSqueak.
> >>                             FixedPreferenceValue
> >>                                 name: 'Watery 2'
> >>                                 description: 'Similar to a nice OS'
> >>                                 type: #UITheme
> >>                                 value: UIThemeWatery2}]
> >>    
> >
> >  
> Hi Matthew,
> > You're really just inventing a half-baked Magritte now.
> Surely, but, for now, Magritte is not in the base system.
> Maybe you can send some advices or ideas about how we can improve
> the preference system.
>
> And the <preference:ziag:zig:> way is still a solution we can adopt back
> if the pharo community prefers it.
>
> > Do
> > yourself a favor and use the real thing. Magritte is far more
> > descriptive and far less verbose than anything you have yet
> > presented. Magritte also already knows how to automatically create both
> > seaside and morphic forms out of a field description. It also
> > knows more ways to look up a field than just selector and block.
> >  
> Anyway, it seems very interesting and I would like to learn a bit about
> Magritte even it is not possible to use it for preferences.
> As an example, could you explain how you specify the themePreference
> with Magritte ?
> Maybe it can help us to improve our implementation.
> Thanks
> alain
>
I'm not sure but I'm starting to understand what Matthew wanted.
I think the description would like this

descriptionThemePreference
   ^ MASingleOptionDescription new
      selectorAccessor: #themePreference;
      label: 'The theme to use for UI look and feel';
      reference: MAClassDescription new;
      options: {UIThemeStandardSqueak. UIThemeWatery2};
      default: UIThemeWatery2;
      priority: 1000;
      yourself

Hmmm, I'm not sure if I should revoke my former mail :)

Norbert


_______________________________________________
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: [Fwd: Re: [ANN] Preference pragmas]

Tapple Gao
In reply to this post by Alain Plantec-4
On Fri, Mar 06, 2009 at 12:02:54PM +0100, Alain Plantec wrote:
> Anyway, it seems very interesting and I would like to learn a bit about
> Magritte even it is not possible to use it for preferences.
> As an example, could you explain how you specify the themePreference
> with Magritte ?
> Maybe it can help us to improve our implementation.

Hehe. I've already done that twice now:

http://lists.gforge.inria.fr/pipermail/pharo-project/2009-March/006202.html

prefTheme
    <preference category: 'User Interface'>
    ^ MASingleOptionDescription new
        options: #( 'Vistary' 'Watery' 'Squeak' 'Soft Squeak' );
        reference: MAStringDescription new;
        autoAccessor: 'theme';
        label: 'Theme';
        priority: 40;
        beSorted;
        yourself

--
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: [Fwd: Re: [ANN] Preference pragmas]

Gary Chambers-4
In reply to this post by NorbertHartl
----- Original Message -----
From: "Norbert Hartl" <[hidden email]>
To: <[hidden email]>
Sent: Friday, March 06, 2009 10:59 AM
Subject: Re: [Pharo-project] [Fwd: Re: [ANN] Preference pragmas]

>> You're really just inventing a half-baked Magritte now. Do
>> yourself a favor and use the real thing. Magritte is far more
>> descriptive and far less verbose than anything you have yet
>> presented. Magritte also already knows how to automatically create both
>> seaside and morphic forms out of a field description. It also
>> knows more ways to look up a field than just selector and block.
>>
> I don't think so. This is a definition of composite value model. The
> value model does not need to reflect the structure of the objects
> that use those preferences. Magritte on the other side would describe
> the other model as it is a meta-model description. And Magritte is a
> lot more heavy weight. So while it looks similar I can't see what you
> are telling.
> But you could use Magritte to describe this model ad then generate
> a UI out of it ;)
>
> Norbert
>

Yes, Magritte seems like overkill for this. After all, the Preference needs
to be modelled anyway otherwise all the classes that defined preferences
(locally) would need Magritte descriptions. Also, I don't think that
Magritte currently supports tree visualisations...

Magritte can be quite handy though as long as one is not particularly
bothered about decent control over the layout of the ui elements (we use it
in the ReportBuilder for catalog-object properties).

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: [Fwd: Re: [ANN] Preference pragmas]

Alain Plantec-4
In reply to this post by Tapple Gao
Matthew Fulmer a écrit :

> On Fri, Mar 06, 2009 at 12:02:54PM +0100, Alain Plantec wrote:
>  
>> Anyway, it seems very interesting and I would like to learn a bit about
>> Magritte even it is not possible to use it for preferences.
>> As an example, could you explain how you specify the themePreference
>> with Magritte ?
>> Maybe it can help us to improve our implementation.
>>    
>
> Hehe. I've already done that twice now:
>  
yes, sorry :)
cheers
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: [Fwd: Re: [ANN] Preference pragmas]

Gary Chambers-4
In reply to this post by NorbertHartl
----- Original Message -----
From: "Norbert Hartl" <[hidden email]>
To: <[hidden email]>; <[hidden email]>
Sent: Friday, March 06, 2009 11:22 AM
Subject: Re: [Pharo-project] [Fwd: Re: [ANN] Preference pragmas]


> On Fri, 2009-03-06 at 12:02 +0100, Alain Plantec wrote:
>> Matthew Fulmer a écrit :
>> > On Fri, Mar 06, 2009 at 10:36:13AM +0100, Alain Plantec wrote:
>> >
>> >> themePreference
>> >>     <preference>
>> >>     ^ ThemePreference
>> >>         ifNil: [ThemePreference := MultiplePreferenceValue
>> >>                         name: 'UITheme'
>> >>                         description: 'The theme to use for UI look and
>> >> feel'
>> >>                         parent: #uiPreferenceNode
>> >>                         type: #UITheme
>> >>                         default: UIThemeWatery2
>> >>                         values: {
>> >>                             FixedPreferenceValue
>> >>                                 name: 'Standard Squeak'
>> >>                                 description: 'Standard Squeak style'
>> >>                                 type: #UITheme
>> >>
>> >>                                 value: UIThemeStandardSqueak.
>> >>                             FixedPreferenceValue
>> >>                                 name: 'Watery 2'
>> >>                                 description: 'Similar to a nice OS'
>> >>                                 type: #UITheme
>> >>                                 value: UIThemeWatery2}]
>> >>
>> >
>> >
>> Hi Matthew,
>> > You're really just inventing a half-baked Magritte now.
>> Surely, but, for now, Magritte is not in the base system.
>> Maybe you can send some advices or ideas about how we can improve
>> the preference system.
>>
>> And the <preference:ziag:zig:> way is still a solution we can adopt back
>> if the pharo community prefers it.
>>
>> > Do
>> > yourself a favor and use the real thing. Magritte is far more
>> > descriptive and far less verbose than anything you have yet
>> > presented. Magritte also already knows how to automatically create both
>> > seaside and morphic forms out of a field description. It also
>> > knows more ways to look up a field than just selector and block.
>> >
>> Anyway, it seems very interesting and I would like to learn a bit about
>> Magritte even it is not possible to use it for preferences.
>> As an example, could you explain how you specify the themePreference
>> with Magritte ?
>> Maybe it can help us to improve our implementation.
>> Thanks
>> alain
>>
> I'm not sure but I'm starting to understand what Matthew wanted.
> I think the description would like this
>
> descriptionThemePreference
>   ^ MASingleOptionDescription new
>      selectorAccessor: #themePreference;
>      label: 'The theme to use for UI look and feel';
>      reference: MAClassDescription new;
>      options: {UIThemeStandardSqueak. UIThemeWatery2};
>      default: UIThemeWatery2;
>      priority: 1000;
>      yourself
>
> Hmmm, I'm not sure if I should revoke my former mail :)
>
> Norbert
>

Or even:

descriptionThemePreference

^MASingleOptionDescription new
     selectorAccessor: #themePreference;
     label: 'UI Theme';
     comment: 'The theme to use for UI look and feel';
     reference: MAClassDescription new;
     optionsAndLabels: {UIThemeStandardSqueak->'Standard Squeak' .
UIThemeWatery2->'Watery 2'};
     default: UIThemeWatery2;
     priority: 1000;
     beRequired;
     yourself

Although the "labels" for options doesn't work in Magritte yet... plus no
description for each selectable theme. Also, to look nicer would benefit
from adding more to Magritte for radio button lists which would then require
setting the widget/morph/seaside-thing class explicitly for each rendering
target.

Using this scheme the change-of-preference notification handling would need
to be implemented for each defined preference also... more and more
complicated and increased replication of code.

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: [Fwd: Re: [ANN] Preference pragmas]

Ramon Leon-5
In reply to this post by Tapple Gao
Hehe. I've already done that twice now:

http://lists.gforge.inria.fr/pipermail/pharo-project/2009-March/006202.html

prefTheme
   <preference category: 'User Interface'>
   ^ MASingleOptionDescription new
       options: #( 'Vistary' 'Watery' 'Squeak' 'Soft Squeak' );
       reference: MAStringDescription new;
       autoAccessor: 'theme';
       label: 'Theme';
       priority: 40;
       beSorted;
       yourself

--
Matthew Fulmer -- http://mtfulmer.wordpress.com/

What happened to trying to slim down the image?  Do we really want to introduce a dependency on a large external library or gasp, include it in the core, just for managing preferences?  I'd much rather see something simpler done with pragmas.  Just because Magritte can be used for something doesn't mean it should.  Just because Magritte is a meta model also doesn't invalidate all future uses of other meta models.  If preferences ends up doing something like a small Magritte lite that looks kinda similar in some respects, it doesn't mean it was wrong to not use Magritte.

Ramon Leon
http://onsmalltalk.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: [Fwd: Re: [ANN] Preference pragmas]

Tapple Gao
On Fri, Mar 06, 2009 at 08:16:30AM -0700, Ramon Leon wrote:

> >
> > Hehe. I've already done that twice now:
> >
> > http://lists.gforge.inria.fr/pipermail/pharo-project/2009-March/006202.html
> >
> > prefTheme
> >    <preference category: 'User Interface'>
> >    ^ MASingleOptionDescription new
> >        options: #( 'Vistary' 'Watery' 'Squeak' 'Soft Squeak' );
> >        reference: MAStringDescription new;
> >        autoAccessor: 'theme';
> >        label: 'Theme';
> >        priority: 40;
> >        beSorted;
> >        yourself
> >
> > --
> > Matthew Fulmer -- http://mtfulmer.wordpress.com/
> >
>
> What happened to trying to slim down the image?  Do we really want to
> introduce a dependency on a large external library or gasp, include it in
> the core, just for managing preferences?  I'd much rather see something
> simpler done with pragmas.  Just because Magritte can be used for something
> doesn't mean it should.  Just because Magritte is a meta model also doesn't
> invalidate all future uses of other meta models.  If preferences ends up
> doing something like a small Magritte lite that looks kinda similar in some
> respects, it doesn't mean it was wrong to not use Magritte.

Imho, there are already too many meta-models in the squeak
world, just as there are too many event frameworks. OB has one
that defines what properties a node in a tree can take on.
FileList has one that describes what actions can be done to a
file. Preferences has one. Etoys had a huge one, but let's not
even go there.

I don't know if it belongs in the core (I don't know what the
core is), but it is a basic service I'd expect a lot of
libraries could depend on.

--
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: [Fwd: Re: [ANN] Preference pragmas]

Gary Chambers-4
True, so many, but none does (or maybe can) do everything to complete
satisfaction for all situations...

Regards, Gary

----- Original Message -----
From: "Matthew Fulmer" <[hidden email]>
To: <[hidden email]>
Sent: Friday, March 06, 2009 4:00 PM
Subject: Re: [Pharo-project] [Fwd: Re: [ANN] Preference pragmas]


> On Fri, Mar 06, 2009 at 08:16:30AM -0700, Ramon Leon wrote:
>> >
>> > Hehe. I've already done that twice now:
>> >
>> > http://lists.gforge.inria.fr/pipermail/pharo-project/2009-March/006202.html
>> >
>> > prefTheme
>> >    <preference category: 'User Interface'>
>> >    ^ MASingleOptionDescription new
>> >        options: #( 'Vistary' 'Watery' 'Squeak' 'Soft Squeak' );
>> >        reference: MAStringDescription new;
>> >        autoAccessor: 'theme';
>> >        label: 'Theme';
>> >        priority: 40;
>> >        beSorted;
>> >        yourself
>> >
>> > --
>> > Matthew Fulmer -- http://mtfulmer.wordpress.com/
>> >
>>
>> What happened to trying to slim down the image?  Do we really want to
>> introduce a dependency on a large external library or gasp, include it in
>> the core, just for managing preferences?  I'd much rather see something
>> simpler done with pragmas.  Just because Magritte can be used for
>> something
>> doesn't mean it should.  Just because Magritte is a meta model also
>> doesn't
>> invalidate all future uses of other meta models.  If preferences ends up
>> doing something like a small Magritte lite that looks kinda similar in
>> some
>> respects, it doesn't mean it was wrong to not use Magritte.
>
> Imho, there are already too many meta-models in the squeak
> world, just as there are too many event frameworks. OB has one
> that defines what properties a node in a tree can take on.
> FileList has one that describes what actions can be done to a
> file. Preferences has one. Etoys had a huge one, but let's not
> even go there.
>
> I don't know if it belongs in the core (I don't know what the
> core is), but it is a basic service I'd expect a lot of
> libraries could depend on.
>
> --
> Matthew Fulmer -- http://mtfulmer.wordpress.com/
>
> _______________________________________________
> 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: [Fwd: Re: [ANN] Preference pragmas]

Ramon Leon-5
In reply to this post by Tapple Gao
> Imho, there are already too many meta-models in the squeak
> world, just as there are too many event frameworks. OB has one
> that defines what properties a node in a tree can take on.
> FileList has one that describes what actions can be done to a
> file. Preferences has one. Etoys had a huge one, but let's not
> even go there.
>
> I don't know if it belongs in the core (I don't know what the
> core is), but it is a basic service I'd expect a lot of
> libraries could depend on.
>
> --
> Matthew Fulmer -- http://mtfulmer.wordpress.com/

Choice is not a bad thing, there is no uber meta model that will suite
everyone's needs all of the time.  There's nothing wrong with projects
creating their own meta model that is suited to exactly what they need.  

For most things, I find pragmas more than sufficient for static metadata and
much lighter weight than Magritte both in code and brain power.  There's
also the nice synergy of having your metadata actually bound to the things
they're representing.  This is an advantage pragmas have over Magritte.

Magritte has the advantage when the metadata starts to become dynamic but
you pay for using it with a much heavier weight code centric approach that
separates the metadata from what it's representing.  Now you have to
maintain a link between the "thing" and the "meta thing" either by either
naming patterns or by using pragmas to bind them.  These are serious
trade-offs to make, it's certainly not a no brainer.

Ramon Leon
http://onsmalltalk.com


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