On Mon, Apr 26, 2010 at 11:20 AM, Steve Wessels <steve at squeak.preeminent.org
> 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.
>


You're welcome!  But if you add it use visible: and enabled:, I thing VW's
is very confusing.  enabled: means visible and indication: means enabled: :)


> - 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>
> 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>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/1c25d845/attachment.htm