Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!ucbvax!bloom-beacon!SRC.DEC.COM!msm From: msm@SRC.DEC.COM (Mark S. Manasse) Newsgroups: comp.windows.x Subject: Re: Keyboard Focus and OverrideShells Message-ID: <8908110002.AA20555@jumbo.pa.dec.com> Date: 11 Aug 89 00:02:00 GMT References: <1989Aug10.001831.13428@agate.berkeley.edu> Sender: daemon@bloom-beacon.MIT.EDU Organization: The Internet Lines: 39 Steve Jacobsen asks how to get keystrokes into an override shell. The first part of the answer is a warning: overrides are not usually something that you want to use, unless you absolutely need the user's response immediately (without them browsing some other window, etc.) Ordinarily, what you really want (except for spring-loaded windows such as pull-down or pop-up menus) is a transient window. If you do use override windows, the simple answer is that you have to be prepared to handle everything yourself. In particular, window managers don't get any control of override windows, and cannot be counted upon to treat them sensibly, since they don't have any way to insert the extra levels of windows needed to safely establish grabs, etc. An override that wants to fiddle with the colormap should: a) set the colormap on the window, and b) use the WM_COLORMAP_WINDOWS property on some window which is visible to the window manager which might have colormap focus. An override that wants to get keyboard input should a) set appropriate grabs on the window b) call XSetInputFocus to set focus to the window both after the window is mapped. You could skip b) if GetInputFocus told you that the focus was PointerRoot. To be extra-friendly, you should call XSetInputFocus whenever the user presses a mouse button in your window, especially if the focus isn't PointerRoot. In essence, this is just like what you would do if you set the input hint to FALSE; you can't expect any help from the window manager, so don't ask for any. Mark