Path: utzoo!attcan!uunet!lll-winken!sun-barr!apple!bloom-beacon!LARRY.MCRCIM.MCGILL.EDU!mouse
From: mouse@LARRY.MCRCIM.MCGILL.EDU (der Mouse)
Newsgroups: comp.windows.x
Subject: Re:  Window Managers and Client Menus
Message-ID: <8909170306.AA16932@Larry.McRCIM.McGill.EDU>
Date: 17 Sep 89 03:06:13 GMT
Sender: daemon@bloom-beacon.MIT.EDU
Organization: The Internet
Lines: 52

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

This is a reasonable idea.  But I have a few nits to pick with your
implementation (surprise surprise :-).

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

You're requiring that a file exist on the WM's machine's filesystem in
order to make the client's menus work?  This seems ugly.  If I, here at
McGill, want to try out a program cooked up by someone at UdeM, I
shouldn't have to copy a file from there to here just to get its menus
working.

One of X's really neat features is its network transparency; let's not
lose that just yet.

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

You're assuming all menus pop up in direct and uniform response to
mouse clicks.  This seems unnecessarily restricting.  Example: a menu
which is invoked by a keystroke.  Example: a menu invoked by clicking
on something on the screen.  Example: a mouse click which sometimes
pops up a menu and sometimes does something else.

I don't know whether twm already does this, but I would also want the
potential for menu items that do different things depending on how
they're selected (left, right, control-left, shift-middle, etc).

> I would like to know what the WM designers (or anybody else) think
> about this idea.

I like the idea but I think it needs more hashing-out.  Perhaps a
separate menu-manager client, with a defined C interface (which is
actually a set of wrappers around ClientMessage sends and receives)?

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu