This will probably work and seems reasonable in a general context. However, for our situation, I feel these are on different levels. Preferences should be defined and taken into account in Pharo-core, meaning without Magritte.
Cheers, Alexandre On 2 Mar 2009, at 18:03, Matthew Fulmer wrote: > On Mon, Mar 02, 2009 at 01:59:03PM +0100, Alain Plantec wrote: >> or simply : >> >> FreeTypeSettings class>>monitorTypeLCD >> <preference:'LCD monitor type' type:#Boolean decsription:'Use of a >> LCD...'> >> ^ MonitorTypeLCD ifNil: [MonitorTypeLCD := PreferenceValue >> default:false] > > Did anybody ever notice my suggestion to use Magritte for > Preferences? > > http://lists.gforge.inria.fr/pipermail/pharo-project/2009-February/005489.html > > ----- Forwarded message from Matthew Fulmer <[email protected]> ----- > > From: Matthew Fulmer <[email protected]> > To: [email protected] > Date: Mon, 16 Feb 2009 15:15:55 -0500 > Subject: Re: [Pharo-project] Preferences refactoring > > 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. > > ----- End forwarded message ----- > > -- > Matthew Fulmer -- http://mtfulmer.wordpress.com/ > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
