yes! and we decided for the builder in the image :)
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project