[comp.windows.x] Keyboard Focus and OverrideShells

csvsj@garnet.berkeley.edu (Steve Jacobson) (08/10/89)

We developed our complex X client on machines running twm.

When we tried running it on a Decstation 3100 running dxsession and dxwm,
we had problems with color map use and keyboard focus.

We usually run twm on the Decstation now, but we've tried to become ICCCM
compliant - we assumed some of our problems might be ICCCM related.

We don't install our custom colormap anymore and we use XSetWindowColormap()
to let the window manager know about desired maps.

This method works with twm and dxwm.

Noting the recent comp.windows.x keyboard focus discussion, we tried setting
XtNinput true for the top level shell where we want keyboard focus.

This worked - dxwm now lets the client get keyboard focus.

However, we use a override shell popup window that includes a widget that
accepts typed input. Under dxsession/dxwm, this widget doesn't receive
keyboard focus, even with XtNinput set to true.

Since an override class shell bypasses the window manager, I guess
it makes sense that an option to set a window manager hint wouldn't do
anything.

Does this mean that an override class shell can't contain a widget that
expects keyboard input? Or is dxsession/dxwm behaving incorrectly?

msm@SRC.DEC.COM (Mark S. Manasse) (08/11/89)

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