[Pharo-project] [Fwd: Re: [ANN] Preference pragmas]
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/
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
----- Original Message ----- From: "Norbert Hartl" <norbert@hartl.name> To: <Pharo-project@lists.gforge.inria.fr> 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
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
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
----- Original Message ----- From: "Norbert Hartl" <norbert@hartl.name> To: <Pharo-project@lists.gforge.inria.fr>; <alain.plantec@free.fr> 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
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/
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
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
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/
True, so many, but none does (or maybe can) do everything to complete satisfaction for all situations... Regards, Gary ----- Original Message ----- From: "Matthew Fulmer" <tapplek@gmail.com> To: <pharo-project@lists.gforge.inria.fr> 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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
participants (5)
-
Alain Plantec -
Gary Chambers -
Matthew Fulmer -
Norbert Hartl -
Ramon Leon