[squeak-dev] Menu Registries

Steve Wessels steve at squeak.preeminent.org
Mon Apr 26 02:45:12 UTC 2010

My mistake.  I see you were no longer referring to the desktop loader  

It seems to me that I should hold off publishing any revision to the  
world menu registry stuff until we get some discussion resolved about  
the approach to take with both the dock and regular menus.

If we agree that the registry approach makes sense it would be a  
trivial matter for me to update the previous code so that it's a  
proper Morphic update.
On Apr 25, 2010, at 9:39 PM, Steve Wessels wrote:

> On Apr 25, 2010, at 5:28 PM, Bert Freudenberg wrote:
>> On 25.04.2010, at 16:58, Stephan Wessels wrote:
>>> I have published this morning to Squeak Source a package that  
>>> provides broader menu registry capability to the World Menu.  The  
>>> package is WorldMenuRegistry-sbw.1.mcz.
>> As I said previously about the DesktopBackgroundLoader package this  
>> is not the right way to package your changes for the trunk. You  
>> must not make a package that modifies the Morphic package. Instead,  
>> please commit an updated Morphic package to the inbox (take a look  
>> at the packages I mention below for an example).
> I've published a version to the trunk that does not modify any  
> outside methods.  The latest version published takes advantage of  
> the dock refactoring published to the trunk in Morphic-kb.428.  If  
> we choose not to go ahead with those changes I'll change my code  
> again.
>> 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.
> Unifying the docking bar and world menu registry is a good idea and  
> I would like to see a uniform approach.  I'm frankly unattached to  
> how we do it just that we get over this and do it.  It's an old  
> problem with multiple solutions proposed in the past.  We should  
> pick a strategy and go forward.  And to further minimize churn I  
> recommend that if someone is going to write this code it should be  
> stated here and we can all evaluate it.
>> - Bert -

More information about the Squeak-dev mailing list