[Cuis-dev] Decentralized menu definition

[Gerald Klix]

I only looked at your examples.

Basically there is only one conceptional difference.
You specify order of the entries by numbers,
like good old basic line numbers.
My solution uses just the order of definition.

If one wants to use my solution in a decentralized
manner, one has to dispatch things procedurally.

There are probably other little differences.
My builder has the notion of a action target and
a model. This helps to send action to
a specific morph, if it only deals with popping
up query windows and the like.
Additionally every text can be replaced by a selector/symbol,
which is sent to the model to retrieve the actual text.
And it is possible to specify a specific text for menus
and buttons. Sometimes I want shorter texts for buttons.

I presume all these bells and wistles can be added
easily to your builder, too.
(If they are not already there)

If your emphasis is on decentralized menu building
your approach is better than mine. I did not
want to solve that issue.


HTH and Best Regards,

Gerald



On 7/21/22 5:32 PM, Hilaire Fernandes via Cuis-dev wrote:
> Le 21/07/2022 à 13:31, Gerald Klix via Cuis-dev a écrit :
>> Let me point out that Haver already has an
>> ActionBuilder package that provides some means
>> to define menus and LayoutMorphs with
>> buttons -- sort of a toolbar -- in one place.
> 
> Thanks for the code example, Gerald, it is helpful.
> 
> As a matter of comparison, here is how you will define a menu and sub 
> menu spread in several image, possible from different package.
> 
> The menu is identified by #exampleMenu used as a pragma tagging the 
> relevant methods. Below this #exampleMenu definition is distributed in 
> four methods.
> 
> *example1_1: menuBuilder*
>      <exampleMenu>
>      menuBuilder newEntry: #entry1 ::
>          label: 'Menu entry 1';
>          icon: #worldIcon;
>          order: 500.
>      menuBuilder newEntry: #entry2 ::
>          label: 'Menu entry 2';
>          help: 'I can have help too';
>          order: 100
> 
> *example1_2: menuBuilder*
>      <exampleMenu>
>      menuBuilder newEntry: #entry3 in: #entry1 ::
>          label: 'Menu entry 3';
>          order: 1.
> 
> *example1_3: menuBuilder*
>      <exampleMenu>
>      menuBuilder newEntry: #entry4 ::
>          label: 'Menu entry 4';
>          order: 1.
>      menuBuilder newEntry: #'Just a drop place' in: #entry1
> 
> *example1_4: menuBuilder*
>      <exampleMenu>
>      menuBuilder newEntry: #entry5 in: #'Just a drop place'::
>          label: 'Menu entry 5'
> 
> To get the menu, you just ask for the #exampleMenu:
> 
> (MenuBuilder on: #exampleMenu) menu popUpInWorld
> 
> Built menus
> 
> 
> The menu entries are ordered as specified in the methods. A third party 
> package can decide in one of its methods to add menu entries in 
> different location of an existing menu hierarchy. To add entries in 
> another menu, it should be done in another method with the add-hoc pragma.
> 
> Now, if it please you, you can replace menu by command. In the 
> implementation of MenuRecord I used a MenuItem instance variable as a 
> drop place to put attributes, to avoid adding a third class Command or 
> attributes to MenuRecord
> 
> It is completely neutral, so we can have:
> 
> MenuBuilder -> CommandBuilder
> 
> MenuRecord -> CommandRecord
> 
> And invoked as:
> 
> (CommandBuilder on: #exampleCommand) getMenu popUpInWorld
> 
> one may extend it to respond to:
> 
> (CommandBuilder on: #exampleCommand) getCircularMorph openInWorld
> 
> 
> (CommandBuilder on: #exampleCommand) getToolbar
> 
> 
> Ideas borrowed from Pharo, implemented differently and likely less 
> capable but easier to understand for me.
> 
> Hilaire
> 
> -- 
> GNU Dr. Geo
> http://drgeo.eu
> http://blog.drgeo.eu
> 
>