Stéphane Ducasse wrote:

the menus world of pharo are dynamically generated from pragmas.

Thanks Steph, I know. What I'm getting at is if we can steer squeak to compatibility by allaying their concerns about a pragma solution. Sean -- View this message in context: http://forum.world.st/World-menu-and-preference-compatibility-tp2067710p2067... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

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