Path: utzoo!mnetor!tmsoft!torsqnt!jarvis.csri.toronto.edu!rutgers!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: <663@thor.wright.EDU>
Date: 19 Sep 89 23:15:27 GMT
References: <654@thor.wright.EDU> <8909181736.AA04699@gaak.LCS.MIT.EDU>
Sender: news@wright.EDU
Lines: 41


Reply to map@lcs.mit.edu:

>   In the application I have, the right mouse button gets a menu,
>   which menu it gets depends where in the master window you are

Yes. I can see where our scheme can run into problems. The condition
that invokes a menu need not just be X events.

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.

3. On a property change of WM_CLIENT_MENU_POP on a client window, the
   WM pops up the specified menu at the current pointer location. When a
   selection is done the WM executes the WM builtin function --
   which can be "f.clientsend <item-id>" to send an X Client Message to
   the client giving it the item-id that was selected. It then unmaps the
   Menu.

4. The client can wait for the Client Message to determine which item
   was selected and whatever it wants to do.

Using this scheme we don't need to have window managers look at client
sub windows. I have not implemented the above yet but I don't see any
problems in the implementation.

Is this general enough now?







Amitava Datta (adatta@cs.wright.edu)