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.ht...
----- Forwarded message from Matthew Fulmer <tapplek@gmail.com> -----
From: Matthew Fulmer <tapplek@gmail.com> To: pharo-project@lists.gforge.inria.fr 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.