[squeak-dev] Menu Registries

Philipp Tessenow phite at nada1.de
Tue Apr 27 07:42:02 UTC 2010

Am 26.04.2010 23:27, schrieb Bert Freudenberg:
> It seems there is consensus brewing for the annotation-based variant of Balázs. Which obviously could be extended for to the world menu too.
> Philipp, do you see any strong advantage your registry-based variant would have over that? 
> - Bert -

Hello again :)

I enjoy reading the discussion as it means everyone seems to get a
clearer view of the system and especially pragmas (or whatever we are
supposed to call them ;) ) - a pity that I went to bed early that evening.

I see and understand most of the arguments, but some stay unclear to me:

Am 27.04.2010 02:13, schrieb Igor Stasenko:
> MenuEntrySpec newFrom: (Dictionary newFromPairs: #(
>                contents 'Well... hello?'
>                help 'Displays the Hello World'
>                location ('Help')
>                target MenuMorph selector inform: arguments ('Hello
>                position first))
> introducing a rigid factors, because of use of globals (here -
> MenuEntrySpec and MenuMorph).

BTW: MenuMorph may be a bad example there could be *any* Object (eg.
self) associated to target.
> In contrast, if we turn it into a set of declarations like this
> <createDockingBarMenuWithPriority: 50>
> <fillDockingBarMenu: #extras priority: 20>

How am I supposed to contribute to Extras->Window Colors (say submenus)?

Am I right that a method which includes
<createDockingBarMenuWithPriority: 50> says: "Hey I am a method that can
contribute in creating a Menu in the DockingBar"?

If yes, that means we need something along <createMenuFor: #dockingBar
WithPriority: 50> to generalize over different menu-systems, right?

What about the priority thing. Isn't that fragile? What if someone with
a higher priority changes the menu I refer to? How do I get the right
priority for the menuEntry I want to create? Also, priorities in other
systems have led to people including lots of random, magic numbers in
their code (having magic numbers in an annotation is not really any
better, is it?). True, strings are "magic", too, but at least I can
*see* them in the menu. I can *see* where my item is going to show up,
as opposed to trying to find out from code.

To get to the point of "introducing rigid factors" by using globals: The
method which uses pragmas/annotations should look somehow like the
following, right?:

MyMenuMethod: extrasMenu
	"Adds myMenu to the Extras-menu"
	<fillDockingBarMenu: #extras priority: 20>
	extrasMenu subMenu addItem: [ :item |
			contents: 'MyMenu';

I see my approach in those issues somehow equal to the pragma-approach.
A class says: "Hello, I offer you a menuSpec to integrate into your
menu" by implementing #menuEntrySpecification.

As MenuSpecs are created with Dictionaries - you can change the things
(eg. by adding a new menu-system besided DockingBar and WorldMenu)
without braking any code (by adding new possible options the dictionary

If you do not like to use the MenuEntrySpec global - it is easy to get
rid of it.
(Make class implement #menuItemFrom: aDict, which answers the
MenuEntrySpec instance.
So you could write:
self menuEntryFrom: (Dictionary newFromPairs: { ... })

I could go on with more points.. but to cut a long story short: I see
both approaches somehow equal. (Just different in style) It looks like
most people prefer the pragma-style as we already use them for
preferences and may use them for system-changing-things in general.

I am perfectly fine with Balázs' approach if it supports the following
points (or is able to support that in the near future):
- it unifies both (and possibly more) menu types
- allows adding/removing menus dynamically (as I've shown in
- is easy to use ( it allows short, readable code for contributing to
menus; readable, documented code for the implementation)
- allows positioning (eg.: I want my menu to be shown just before the
Help-menu; I want my menu to be placed in some sub-menu) without
reverting to some magic numbers
- changing things (eg. adding a on-click-highlight-color or something)
doesn't break existing code

As far as I this is already done or is at least possible (Am I right?
I'm not sure on the dynamically adding menus issue).

May the DockingBar be with you :)

More information about the Squeak-dev mailing list