<br><br><div class="gmail_quote">On Mon, Apr 26, 2010 at 8:54 AM, Steve Wessels <span dir="ltr"><<a href="mailto:steve@squeak.preeminent.org">steve@squeak.preeminent.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
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.<br>
</blockquote><div><br></div><div>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.</div>
<div><br></div><div>e.g.</div><div><br></div><div><div>browseVersions</div><div><span class="Apple-tab-span" style="white-space:pre"> </span><menuItem: #(#Versions #store 'Versions')</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>nameKey: nil</div>
<div><span class="Apple-tab-span" style="white-space:pre"> </span>enablement: #areConnectedAndSelected</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>indication: nil</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>menu: #(#listMenu)</div>
<div><span class="Apple-tab-span" style="white-space:pre"> </span>position: 90.01></div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>DbRegistry doIfOnlineImage: </div><div><span class="Apple-tab-span" style="white-space:pre"> </span>[ self selection notNil</div>
<div><span class="Apple-tab-span" style="white-space:pre"> </span>ifTrue: [ self spawningBrowserClass browseVersionsOfNamespaceOrClass: self selection ]</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>]</div>
<div><br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
I may be the only voice asking for real dfynamic menu management.<br><font color="#888888">
<br>
- Steve</font><div><div></div><div class="h5"><br>
<br>
On Apr 26, 2010, at 8:31 AM, Tim Felgentreff <<a href="mailto:tim@nada1.de" target="_blank">tim@nada1.de</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Mon, 2010-04-26 at 00:28 +0200, Bert Freudenberg wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
There are now two contenders for customizing the docking bar in the inbox,<br>
Morphic-kb.428 and Morphic-phite.428. We should discuss the advantages of<br>
either approach in this thread. And I think it would be a good idea to unify<br>
the docking bar registry and the world menu registry - at least they should<br>
use a similar mechanism.<br>
</blockquote>
<br>
I like Philipp's approach to unify the world menu and the bar, however,<br>
as we are starting to use pragmas for preferences as well, we might want<br>
to go into the direction of pragmas for different kinds of configurable<br>
behaviour.<br>
Then again, windowColorSpecs work much like Philipp's approach, too, and<br>
I like<br>
and understand them (not to mention I can easy and fast grep for<br>
'Specification' using Cmd+W).<br>
I would tend to favor Philipp's approach right now, especially as as<br>
adding nested menus seems more straightforward to me. But we might want<br>
to start generalizing configuration and if we use pragmas for that a<br>
newcomer might find it easier to recognize configurations as such.<br>
<br>
Just my 2 pieces of eight<br>
-Tim<br>
<br>
<br>
</blockquote>
<br>
</div></div></blockquote></div><br>