- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Preferences refactoring

by Matthew Fulmer

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/

Feb. 16, 2009

Re: [Pharo-project] Loading Polymorph

by StÃ©phane Ducasse

ok do you imply that I should be able to push in the release the latest version without problem? Excellent! Stef On Feb 16, 2009, at 1:22 PM, Gary Chambers wrote: > Loads from 42 upwards should be ok as normal. Polymorph-Widgets- > gvc-45 now > on SqueakSource > with some lint related changes and a few other goodies ;-) > > Regards, Gary > > ----- Original Message ----- > From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Sunday, February 15, 2009 2:53 PM > Subject: Re: [Pharo-project] Loading Polymorph > > >> I will try to see what I can do to load it. >> >> Stef >> >> >>> Latest Polymorph-Widgets versions (from 41 to 42) require the MC >>> workaround to load/merge, unfortunately. >>> Anything down to drawing... in this case the change to dropShadows. >>> >>> Regards, Gary >>> _______________________________________________ >>> 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 > > > _______________________________________________ > 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] Message sent but not implemented (part one)

by StÃ©phane Ducasse

thanks!!!!! Stef On Feb 16, 2009, at 10:49 AM, Damien Cassou wrote: > On Sat, Feb 14, 2009 at 2:20 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> it would be good to open a bug entry for each group (per class) of >> problems. > > Issues 528 to 570 > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > _______________________________________________ > 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] Distributed versioning ... MonticelloHub?

by StÃ©phane Ducasse

sorry you lost me on this one. Stef On Feb 16, 2009, at 10:30 AM, Damien Cassou wrote: > On Sat, Feb 14, 2009 at 12:17 PM, Keith Hodges <keith_hodges(a)yahoo.co.uk > > wrote: >> I think that you will find that you have most of them already. > > Yes, only issue #456 (which includes the fix and is already in > PharoInbox) needs to be included. I guess there are no or very few > overrides left. > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > _______________________________________________ > 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 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