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
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100426/bfdcc464/attachment.htm