Re: Menus

[Gelder <gelderk natlab research philips com>]

> > I suppose there's no specific advantage to trimming menus per se,
> > if that was a standalone feature (i.e. implemented for its sake
> > alone, not as the side effect of a greater functionality). But I
> > would say that the more customizability we give the user
> > (and--here's the point--the administrator), the better things will
> > be for the greater whole. If we make it easy to turn off, there is
> > no reason we should avoid this feature (aside from
> > coding/implementation details).
> 
> I assume that administrators are quite capable to disable three lines in the
> sourcecode to take out menu items they don't want. this is something where
> customized menus are useful, like public internet terminals or suchlike. but
> in most of these cases, you have to edit in the source anyway.

Well, then imagine a new type of terminal being installed. Instead of
hacking through all the source-codes for all programs that are
suitable for that terminal, the administrator creates a new version of
the configuration, changes once what needs to be changed and is done
for all programs.

Another advantage would be in the coding itself; since the programmer
can not configure the menus anymore, he/she'll have to use
library-calls like add_quit() in order to add the quit capabilities to
the application. That's a lot faster than create_toolbar(),
add_filemenu(), add_quitentry(), hook_quitmethod_to_quitentry(),
hook_quitmethod_to_quitkeystroke().

Once it is generally accepted that the ``App''-menu is to be used
instead of the file-menu to place the quit-entry (or any other kind of
possible change), you do _not_ have to dive into your code again.

Easier for the programmer, the distributor, the administrator and the
user, I think.

+--- Kero ------------------ kero@dds.nl ---+
| I ain't changed,                          |
| but I know I ain't the same               |
+--- M38C --- http://huizen.dds.nl/~kero ---+