Path: utzoo!attcan!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: Window Managers and Client Menus
Keywords: Window Managers, Client Menus
Message-ID: <653@thor.wright.EDU>
Date: 15 Sep 89 16:41:35 GMT
Sender: news@wright.EDU
Lines: 96

If you are building an X client and don't quite like the Xt support
for creating popup menus you may want to consider the following:

  Why not have the X window manager display and manage menus for clients?
  (Of course, the window manager would need to inform the X client when
  a menu item gets selected)

First, why would anybody want to do this?
------------------------------------------

1. One of the reasons (most probably) why we choose a particular window 
   manager is because we like the way it manages its menus.

2. Popup menus using Xt widgets (if you can get them to work
   correctly) don't look (or feel) as good as the menus used by the
   window manager.

3. A lot of code is duplicated in all X clients to handle menus. I
   have seen enough questions being asked in this news group about how to
   get pop up menus to work to safely assume that it does take some time 
   to understand the Xt popup support. We could save a lot of time in 
   bringing up a client.

4. The user interface is not as uniform as we would like them to be
   since every X client is probably going to come up with its own
   way of dealing with its menus. If window placement, decoration and
   basic window manipulation (moving, resizing, iconifying, etc.) are 
   to be handled by the window manager to provide a ``uniform''
   interface so should the management of menus since it is such a
   basic operation in a windowing environment.

5. No X client will be tied down to one way of displaying and managing
   menus. Assuming that all window managers provide this facility,
   X client menus will look and feel different when using different
   window managers.

One such implementation:
------------------------

We (Shane Dawalt and I) have modified TWM to provide this facility
(and call it TWM+). The following is a brief description of how it
works.

1. Client menus and mouse button bindings are specified in a separate
   file. Menus are defined the way they are in the .twmrc file
   (so that we could use the same parser). 

2. The client hangs a CLIENT_MENU property on its toplevel window
   specifying the filename from where the client's menus can be read
   in by TWM+.

3. TWM+ grabs buttons in client's toplevel window which binds to client 
   menus just the way it used to when handling button binds with the window 
   context.

4. Client menus are displayed when the proper button event is received
   by TWM+. If an item is selected TWM+ performs the corresponding
   action. A new TWM+ builtin function `f.clientsend' was added which 
   can be used to send a ClientMessage event to the client with the
   data field containing a string which can be used (in the client) to
   determine which item was selected. An sample client menu defn. in
   TWM+ is shown below.

	menu "menu2"
	{
	"Menu 2"	f.title
	"Selection 1"	f.clientsend "menu2:1"
	"Selection 2"	f.clientsend "menu2:2"
	"Selection 3"	f.clientsend "menu2:3"
	"Pull-right"    f.menu "menu1"
	"Move"		f.move
	}

The whole interaction with X client and the WM seems to work quite
well. We did not notice any delay in getting an X client to respond to
menu selections. 

There are currently some limitations, e.g. since only toplevel windows
are seen by the WM, client menus can only work when defined for such
toplevel windows. For a number of implementations I have found that
this is not too much of a limitation.

I would like to know what the WM designers (or anybody else) think
about this idea. Can such a facility be made a standard for all X WMs?
Of course, we would have to come up with a standard way of defining menus.
This should not be too much of a problem.

If you need diffs for TWM+, I would be happy to provide them.

++adatta

email: adatta@cs.wright.edu
==================================
Amitava Datta
Email: adatta@cs.wright.edu
Phone: (513)-259-1391 (Office)