ellis@cadillac.siemens.COM (Ellis Cohen) (12/23/87)
We are revisiting the way our window manager deals with clients
that explicitly set the input focus. None of the clients we have
written do this -- they depend on the window manager to handle
input focus. In order to make certain that we do right in handling
clients that set the input focus themselves, we'd like to hear how and
why you do that.
Do you set the input focus
a) To a subwindow of a top-level window?
b) To move from one top-level window to another one that is part
of the same application?
c) On the activation of a Passive Button Grab in a top-level or sub-
window?
d) On the activation of a Passive Key Grab in a top-level or sub-
window?
e) On entering the window?
f) For some other reason.
Our window manager currently supports both real-estate driven,
and click-to-type models, and protects push-style clients (those that do
not explicitly set the input focus, or do only when they already have it)
from pull-style clients (cases c,d,e above) in the following way.
When running real-estate driven, WE set the focus back to PointerRoot
when the uses moves the pointer out of a pull-style application.
When running click-to-type, and the user clicks in a push-style
window, WE set the focus to that window.
So even if there are pull-style applications around, a window manager
should be able to protect against their stealing the screen away from
push-style applications.
We'd be interested in hearing comments on the approach our window manager
takes, but we are especially interested in hearing from writers of
pull-style applications about why they've chosen that path.
Ellis Cohen
ellis%cadillac.siemens.com@princeton.edu
Siemens RTL Tiled Window Project
105 College Rd East
Princeton NJ 08540
(609) 734-6524