World menu and preference compatibility

>
> 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.
>
> http://forum.world.st/Squeak-dev-World-Menu-Registry-td2064576.html
> --
> View this message in context: http://forum.world.st/World-menu-and-preference-compatibility-tp2067710p2067710.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> 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.
>  

> 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

>>>
>> 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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project