Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!snorkelwacker!bloom-beacon!eng.sun.COM!smarks
From: smarks@eng.sun.COM (Stuart W. Marks)
Newsgroups: comp.windows.x
Subject: Re: No keyboard events on overrideShell popups
Message-ID: <9003200426.AA07580@trantor.Eng.Sun.COM>
Date: 20 Mar 90 04:26:14 GMT
References: <9003152143.AA07322@harley.nsc.com>
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 54


| Is there a solution to the problem of not receiving keyboard events in an
| overrideShell popup under olwm (X11R4, Fixes 1-6, Sun4/110, SunOS 4.0.3)?
| 
| I have written an application using the Athena widgets and the toolkit
| intrinsics which does set the input resource to true using the XtSetArgs
| mechanism when creating the popup, and which works correctly with each of the
| other five choices of window manager available under R4, but which refuses
| to accept keyboard events under olwm.  I note that there has been no response
| to Jim Frost's similar question posted 2-March to comp.windows.x.  Perhaps
| there IS no solution, but could someone in the know please respond?

This is yet another one of those phenomena that works by coincidence most
of the time, but which isn't guaranteed to work all of the time.  The
problem is that under many window managers, including the "other five"
window managers available from MIT, the input focus mode is usually (but
not always) in PointerRoot.  This mode lets keystrokes fall to whatever
window is under the pointer, like your overrideShell popup.  Olwm maintains
tighter control over the input focus, rather than using PointerRoot mode.
The problem is that you create an overrideShell widget, which is by
definition *not* managed by the window manager.  Since the window manager
manages the input focus, you can't get keyboard input.

Setting the XtNinput resource to True doesn't help, because all that does
is tell the window manager that the window wants the input focus.  This
doesn't help if the window manager isn't managing the window in the first
place.

Olwm isn't alone in this regard.  DEC's window manager, dxwm, will also
exhibit this behavior.  You can also set up twm to show this problem.  Try
using twm's f.focus function to move your input focus around.  You'll find
that it will be unable to direct the input focus to your overrideShell
widget.

So, that's the background.  What's the solution?  Either manage the input
focus yourself (sort of), or let the window manager do it.

If you insist on using an overrideShell popup, you must do something
drastic like grabbing the keyboard while the popup is up.  This is pretty
antisocial, though; the user won't be able to type anywhere else while your
popup is active.  Do you really want that?

I would suggest that you use a transientShell popup instead.  This lets the
window manager manage the window and the focus.  Many window managers will
provide less decoration for transientShell popups than for regular windows.
For instance, olwm will provide a border but no title bar for transient
windows.

s'marks

--
Stuart W. Marks			ARPA: smarks@eng.sun.com
Window Systems Group		UUCP: sun!smarks
Sun Microsystems, Inc.