February 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Preferences refactoring

by Matthew Fulmer

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/

Feb. 16, 2009

Re: [Pharo-project] Preferences refactoring

by Gary Chambers

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(a)gmail.com> To: <Pharo-project(a)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(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project Regards, Gary

Feb. 16, 2009

Re: [Pharo-project] "Real" packages.

by Alexandre Bergel

I watched at the video, looks cool! Alexandre On 10 Feb 2009, at 22:28, Michael van der Gulik wrote: > > > On Wed, Feb 11, 2009 at 9:21 AM, David RÃ¶thlisberger <squeak(a)webcitas.ch > > wrote: > > > So if we had real packages in Pharo as first class entities, OB > would be much faster > and simpler to maintain. Right now, OB models packages and class > cats itself, has to > take the information from both the Monticello's working copy > managers and the > SystemOrganizer. This is a mess and a huge pain, but what can we do. > We should really invest in bringing real packages to Pharo. > > > If you want "real" packages, I've implemented them in Squeak: > > http://gulik.pbwiki.com/Namespaces > http://gulik.pbwiki.com/Packages > > The places the code is held, including a video and a Squeak image is > linked from here: > http://gulik.pbwiki.com/SecureSqueak > > I'm not interested in Pharo, but the code is there and is released > under the MIT license if anybody else wants it. > > Gulik. > > -- > http://people.squeakfoundation.org/person/mikevdg > http://gulik.pbwiki.com/ > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Feb. 16, 2009

Re: [Pharo-project] Preferences refactoring

by Alain Plantec

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

Feb. 16, 2009

Re: [Pharo-project] Preferences refactoring

by Alain Plantec

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

Feb. 16, 2009

Re: [Pharo-project] Mike we need some fixes for mime.... :)

by Michael Rueger

StÃ©phane Ducasse wrote: >> Issue 520: MIMEDocument class(Object)>>doesNotUnderstand: >> #resetMIMEdatabase >> http://code.google.com/p/pharo/issues/detail?id=520 Hmm, there isn't a MIMEDocument>>initialize anymore, so the bug is introduced by someone reintroducing/overriding the class initialize method. Michael

Feb. 16, 2009

Re: [Pharo-project] Preferences refactoring

by Gary Chambers

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(a)acm.org> To: <Pharo-project(a)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(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 16, 2009

Re: [Pharo-project] Preferences refactoring

by Michael Rueger

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

Feb. 16, 2009

Re: [Pharo-project] Preferences refactoring

by Gary Chambers

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(a)gmail.com> To: <Pharo-project(a)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(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 16, 2009

Re: [Pharo-project] Preferences refactoring

by Alain Plantec

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(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > >

Feb. 16, 2009