Re: Menus

["Khimenko Victor" <gnome-gui khim sch57 msk ru>]

5-Nov-98 18:13 you wrote:
> On Thu, 5 Nov 1998, Tom Vogt wrote:
>> as much as I like configurability, why fix what ain't broken? or in other
>> words: where is the actual advantage of customizable menus? I fail to see
>> how the user gains, except for having something to play around with.

>    Maybe `broken' is in the eye of the beholder, at least to a certain
> extent?  There's something quite appealing (at least to me) in the notion
> of assembling a `favourites' menu of commands I use often.  I guess full
> accelerator key support would alleviate this.

Fo example in Netscape Communicator I'm have "Encoding" submenu as second level
submenu in "View" menu. But it's by far most used submenu here in Russia !
I'll be really glad to see it as top-level menu (or may be even better just few
items from there in button bar of my Netscape window). But I'm could easily
imagine that this menu will be [almost] useless for english-speacking users.
Or gwp: when you are in "text entering mode" you'll need one set of tools handy,
if you are in "editor" mode you'll need other set of tools, etc.

Of course it's almost useless in M$ Office since you must tune each and every
application separately. But my toolbars (not menu bars -- I'm does not use menu
very often) and all "custom-made" in MS Dev. If this will be themes-driven this
could be even more usable thing. And of course flame wars like "where should be
"About..." and "Quit" things placed?" will be closed: in Windows theme this
will be File-Exit and Help->About while in Mac theme this will be Foot->About
(we could not use real "apple menu" of course :-) and in GNOME theme this will
be Foot->Quit ...

>    I do take your point about the amount of work involved; but I wonder if
> it would only have to be done once: something like externalizing (part
> of?) the GnomeUIInfo stuff used to build menus.  Erm, I haven't thought
> about that much.

Of course if all this stuff will double effort needed to develop each and
every GNOME application then this approach should be throwed out. But IMO
this could be made once. Of course all existing applications should be redone
after change but we have not so much mature GNOME applications now anyway
(except of GIMP, of course and GIMP is parent of GNOME, not GNOME application
just now :-) I'm even think that this approch will give as possibility to
create "self-adjustable" menus without applications rewriting if this approach
turned out to be usable (I'm not sure that this approach will be usable but
who knows?).