Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!ncrlnk!wright!odin!adatta
From: adatta@odin.wright.edu (Amitava Datta)
Newsgroups: comp.windows.x
Subject: Re: Window Managers and Client Menus
Message-ID: <671@thor.wright.EDU>
Date: 24 Sep 89 23:44:47 GMT
References: <663@thor.wright.EDU> <654@thor.wright.EDU> <1839@bacchus.dec.com>
Sender: news@wright.EDU
Lines: 103

klee@gilroy.pa.dec.com (Ken Lee) writes ....

>  ..... Potential advantages [to WMs handling client menus] 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.

But how will you get all clients to have the same kind of menus to pop
up regardless of which WM is being used? This is the primary goal.

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

Again, different clients will still use different kinds of menus
making the user interface non-uniform. 

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

You can never force one ``common widget set'' on all clients and WMs. 

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

The way I have it implemented now, client menus can be invoked even
without client intervention. Just specify the key or mouse button
binding that the client wishes to bind to a menu popup just as you
would using the WM's startup file for the WM menus. The scheme to have
the user specify the popup will be an addition and can be used when
the client wants to popup menus based on non-X "events". 

> Your scheme also adds a number of disadvantages, such as complexity,

If you don't find setting size hints and having the WM respond to
those requests complex, I don't see how you find my scheme of poping
up a window via hints more complex . It uses the same mechanisms in X.
Believe me, it is not even close to being complex. 

> lots more round trips to the X server, greater operating system context
> switching, 

There's enough of that going on in an X environment. That's not my
doing.  I am trying to add a missing functionality using whatever's
available in X.  I have implemented this (not the revised scheme) and
I don't see any increase in response time. 

> and requiring a particular window manager look & feel.

If you mean one that supports Client Menus, yes. But if people feel
this is an essential feature to have then this could be made a
standard. I know a few who would like it as a ICCCM standard.

> Plus, the client is dead in the water if the window manager dies.

Why should it be "deep in the water"? The user would do just what we
do today -- go to a shell and run the window manager again and send a
bug report to the window manager writers. When the WM comes up it can
read in all menu defs from the WM_CLIENT_MENUS property. All WMs do
that to read in current geometry related and name hints associated to
each window.

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

Instead of having a home grown solution known only to a few clients
what I am suggesting is more general and can be made a standard
without having the WM writers too much of a hassle to implement. I
have just done this with TWM and find that it is really a very simple
extension.

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

I have not used MWM. If this WM has anything special that other WMs do
not provide then you will have clients tied down to MWM. This
shouldn't happen and if MWM provides a better (or simpler) scheme to
handle client menus then we should try and make THAT a standard.

The way I see it, there should be some mechanism in the X environment
by which the user can be provided with a way to get the same kind of
menus when one is requested regardless of which client the user is
interacting with. Currently there isn't a way to do that in X. Once we
have them we should discourage clients to pop up their "own" menus and
have them use the WMs menus since, most likely, the user likes the way
those menus look and feel. At least we will have a uniform interface
to all menu. 

Amitava Datta (adatta@cs.wright.edu)