I will post replies I get in pharo-project here as a resource in this
conversation:

Pharo menus can have pre-condition blocks:
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'] 

A take on the pros and cons of existing preference style v.s. Pharo menu
style:
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. 

-- 
View this message in context: http://forum.world.st/Squeak-dev-World-Menu-Registry-tp2064576p2067924.html
Sent from the Squeak - Dev mailing list archive at Nabble.com.