On Apr 27, 2010, at 5:51 07PM, Alain Plantec wrote:
> Sean P. DeNigris a écrit :
>> There is a conversation on squeak-dev right now about how to handle world
>> menus / prefs / docking bar.
>>
>> The participants seem to be leaning toward using pragmas, and I am a strong
>> voice for compatibility where we can, especially on the fundamentals.
>>
>> If anyone can/wants to share their experience with the pragma solution so
>> far (there is a question in particular about whether it allows dynamic menu
>> additions/removals), it would be relevant.
>>
> Hi Sean,
> you can declare a menu item with a precondition block.
> the menu item is not added to the menu if the precondition is false.
> We have one example in the core. See the precondition in the #'Software
> update' item.
>
> WorldState class>>systemOn: aBuilder
> <worldMenu> (aBuilder item: #System)
> order: 4.0;
> withSeparatorAfter;
> icon: MenuIcons smallConfigurationIcon;
> with: [
> (aBuilder item: #'About...')
> order: 0;
> action: [Smalltalk aboutThisSystem].
> (aBuilder item: #'Software update')
> order: 1;
> precondition: [self showUpdateOptionInWorldMenu];
> action: [Utilities updateFromServer];
> help: 'Load latest code updates via the internet']
>
> Cheers
> Alain
Comparing Settings to Preference Annotations might gleam at the difference you
might expect between menu annotations in Pharo and Squeak.
In Pharo the method contains a simple annotation with no args, and the method
contains code for building a menuitem using the builder passed as argument,
My speculation: If following the existing preference-style, Squeak will
probably use an annotation with more args, with the method body containing the
actual action.
i.e. Alains example would be written something like:
WorldState class>>aboutMenuItem
<menuItemIn: #('WorldMenu' 'System')
order: 0
label: 'About... '>
Smalltalk aboutThisSystem
WorldState>>updateFromServertMenuItem
<menuItemIn: #('WorldMenu' 'System')
order: 1
label: 'About... '
visible: #showUpdateOptionInWorldMenu
help: 'Load latest code updates via the internet'>
Utilites updateFromServer
Both approaches have their pros and cons.
The one in Pharo depends on a builder responding to certain messages, so
expanding the API might lead to breakage if you try to load into an old image.
You also have to define new annotation keywords for each menu you want to build
this way, .
The one for Squeak might suffer a risk of needing a large amount of
permutations of annotations , depending on which PluggableMenuItemSpec
properties you'd want to be able to leave optional.
In short: In Pharo you have access to the builder in the method, while in
Squeak (based on how Preferences annotations work) I'd expect they end up with
a builder parsing an annotation instead.
Cheers,
Henry
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
