[squeak-dev] Menu Registries
bert at freudenbergs.de
Mon Apr 26 21:27:15 UTC 2010
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.
>> <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
>> 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
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 -
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Squeak-dev