Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uwm.edu!uakari.primate.wisc.edu!pikes!boulder!stan!toml
From: toml@Solbourne.COM (Tom LaStrange)
Newsgroups: comp.windows.x
Subject: Re: Window Managers and Client Menus
Message-ID: <2422@ninja.Solbourne.COM>
Date: 18 Sep 89 14:09:59 GMT
Organization: Solbourne Computer Inc., Longmont, Co.
Lines: 34

>> 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. 
>
>Yes, keys can be bound to TWM built-in functions - popingup a client
>menu in this case. TWM already supports that. (I have never seen any
>application poping up a menu on a key press. But I agree. We must not
>restrict people from doing that - we aren't).

Have you tried this?  I don't think you can pop up a menu from the keyboard.

>> Example: a menu invoked by clicking
>> on something on the screen.  
>
>That ``something on the screen'' has to be some window. CLIENT_MENU
>can be defined for that window to popup a menu on the specific mouse
>click or key. Right now we don't have an easy way of supporting client
>menus on windows which are not ``top-level''. X WMs don't manage sub
>windows. A kludged up version exists. Should be able to find a cleaner
>solution for that. 

Window managers will look at inner windows in R4 if told to do so.  I'm 
referring to the WM_COLORMAP_WINDOWS property which lists child windows
that have their own colormaps.  Something similar could be done with
a WM_CLIENT_MENU_WINDOWS property.

I like the idea.

--
Tom LaStrange

Solbourne Computer Inc.    ARPA: toml@Solbourne.COM
1900 Pike Rd.              UUCP: ...!{boulder,nbires,sun}!stan!toml
Longmont, CO  80501