The consensus so far is that you can do dynamic menus with the pragma
based approach as well.

Bert, what you call here 'annotation based' is called 'Pragma' in the
code. Which is confusing, see the other thread.

I prefer the registry-based approach.

--Hannes



On 4/26/10, Bert Freudenberg <bert at freudenbergs.de> wrote:
> On 26.04.2010, at 20:20, Steve Wessels wrote:
>> That would work splendidly.  In fact, that's lovely because you would
>> create your own "private" registry and then kill it when your code leaves.
>>
>>
>> A blended approach like this covers my concern and I admit I never
>> considered it.  Silly of me.  Thanks for the tip.
>>
>> - Steve
>>
>> On Apr 26, 2010, at 1:12 PM, Eliot Miranda <eliot.miranda at gmail.com>
>> wrote:
>>
>>>
>>>
>>> On Mon, Apr 26, 2010 at 8:54 AM, Steve Wessels
>>> <steve at squeak.preeminent.org> wrote:
>>> The "Pragma" approach is easier to utilize in code.  However we are
>>> giving up the ability to dynamically change menu contents with that
>>> approach.  Yes, we can modify a menu on install and release of a package,
>>> and that's currently the immediate problem we are trying to solve.  But
>>> if a developer wants the application to change a menu dynamically after
>>> the package is installed, I don't think the coded "pragma" approach will
>>> work.
>>>
>>> In the VW scheme there is the possibility to add an enablement selector
>>> and an indication selector, which between them decide whether an entry is
>>> visible and whether it is enabled.  So there's nothing in the pragma
>>> approach per se that prevents dynamic menus.
>>>
>>> e.g.
>>>
>>> browseVersions
>>> 	<menuItem: #(#Versions #store 'Versions')
>>> 		nameKey: nil
>>> 		enablement: #areConnectedAndSelected
>>> 		indication: nil
>>> 		menu: #(#listMenu)
>>> 		position: 90.01>
>>>
>>> 	DbRegistry doIfOnlineImage:
>>> 		[ self selection notNil
>>> 			ifTrue: [  self spawningBrowserClass browseVersionsOfNamespaceOrClass:
>>> self selection ]
>>> 		]
>>>
>>>
>>> I may be the only voice asking for real dfynamic menu management.
>>>
>>> - Steve
>>>
>>>
>>> On Apr 26, 2010, at 8:31 AM, Tim Felgentreff <tim at nada1.de> wrote:
>>>
>>> On Mon, 2010-04-26 at 00:28 +0200, Bert Freudenberg wrote:
>>> There are now two contenders for customizing the docking bar in the
>>> inbox,
>>> Morphic-kb.428 and Morphic-phite.428.  We should discuss the advantages
>>> of
>>> either approach in this thread. And I think it would be a good idea to
>>> unify
>>> the docking bar registry and the world menu registry - at least they
>>> should
>>> use a similar mechanism.
>>>
>>> I like Philipp's approach to unify the world menu and the bar, however,
>>> as we are starting to use pragmas for preferences as well, we might want
>>> to go into the direction of pragmas for different kinds of configurable
>>> behaviour.
>>> Then again, windowColorSpecs work much like Philipp's approach, too, and
>>> I like
>>> and understand them (not to mention I can easy and fast grep for
>>> 'Specification' using Cmd+W).
>>> I would tend to favor Philipp's approach right now, especially as as
>>> adding nested menus seems more straightforward to me. But we might want
>>> to start generalizing configuration and if we use pragmas for that a
>>> newcomer might find it easier to recognize configurations as such.
>>>
>>> Just my 2 pieces of eight
>>> -Tim
>>>
>>>
>>>
>>>
>>>
>>
>
>
> 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 -
>
>
>