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.

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
>
>