Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!wuarchive!brutus.cs.uiuc.edu!apple!agate!shelby!decwrl!gilroy.pa.dec.com!klee
From: klee@gilroy.pa.dec.com (Ken Lee)
Newsgroups: comp.windows.x
Subject: Re: Window Managers and Client Menus
Message-ID: <1839@bacchus.dec.com>
Date: 20 Sep 89 16:55:06 GMT
References: <663@thor.wright.EDU> <654@thor.wright.EDU> <8909181736.AA04699@gaak.LCS.MIT.EDU>
Sender: news@decwrl.dec.com
Reply-To: klee@decwrl.dec.com
Organization: DEC Western Software Laboratory
Lines: 55

In article <663@thor.wright.EDU>, adatta@odin.wright.edu (Amitava Datta)
writes:
> Going by your suggestion, let me revise our scheme:
> 
> 1. X client posts all the menu defns. via WM_CLIENT_MENUS. No bindings
>    needs to be specified.
> 
> 2. Client decides *when* to popup *which* menu. This is done by
>    setting WM_CLIENT_MENU_POP to have the name of the menu to popup on
>    the top level window.

I think this kind of generality removes the last advantage of a "menu
manager" client.  Potential advantages I see are:

1.  Centralized code makes clients smaller and improves performance.
But, many systems now have shared libraries which do the same thing
more gracefully.  Shared libraries should be available on most or all
workstations within the next year or two.

2.  Menus are difficult to write.  Yes, but the big widget sets
(DECwindows, Motif, HP, OpenLook) all have menu widgets that make menu
handling easy.

3.  User interface consistancy.  A common widget set or style guide is
probably a better place for this.  Besides, you want the whole user
interface to be consistent, not just the menus.

4.  Response time.  A client involved in a detailed calculation may not
get back to event polling for awhile.  A separate menu management
client and your operating system's scheduler allow the to popup
anyway.  The client won't be able to act on the menu selection
immediately, but the user gets better feedback.  Unfortunately, the
scheme outlined above requires client intervention before the menu can
be displayed, removing this advantage.

Your scheme also adds a number of disadvantages, such as complexity,
lots more round trips to the X server, greater operating system context
switching, and requiring a particular window manager look & feel.
Plus, the client is dead in the water if the window manager dies.  A
particular client, or group of clients, may want to use a menu manager
to work around particular problems (I have done this with some
success), but I think that a general solution at this level has too
many of it's own problems.  (If you want to talk about a general user
interface server, rather than just a menu server, however, I might be
interested.)

By the way, the Motif window manager has minimal support for client
defined menus.  This is about as far as I'd want to go for menu
management.  These menus are integrated with the window manager look &
feel, but the client should be able to operate without them.

Ken Lee
DEC Western Software Laboratory, Palo Alto, Calif.
Internet: klee@decwrl.dec.com
uucp: uunet!decwrl!klee