From xemacs-m  Tue Feb  4 22:46:41 1997
Received: from CNRI.Reston.VA.US (CNRI.Reston.VA.US [132.151.1.1])
	by xemacs.org (8.8.5/8.8.5) with SMTP id WAA24033
	for <xemacs-beta@xemacs.org>; Tue, 4 Feb 1997 22:46:36 -0600 (CST)
Received: from newcnri.cnri.reston.va.us by CNRI.Reston.VA.US id aa00852;
          4 Feb 97 23:46 EST
Received: from anthem.CNRI.Reston.Va.US by newcnri.CNRI.Reston.Va.US (SMI-8.6/SMI-SVR4)
	id XAA11101; Tue, 4 Feb 1997 23:46:34 -0500
Received: by anthem.CNRI.Reston.Va.US (SMI-8.6/SMI-SVR4)
	id XAA26661; Tue, 4 Feb 1997 23:46:33 -0500
Date: Tue, 4 Feb 1997 23:46:33 -0500
Message-Id: <199702050446.XAA26661@anthem.CNRI.Reston.Va.US>
From: "Barry A. Warsaw" <bwarsaw@anthem.cnri.reston.va.us>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: Kyle Jones <kyle_jones@wonderworks.com>
Cc: xemacs-beta@xemacs.org
Subject: Keyboard focus policy (was Re: 19.15b92 - Pure storage exhausted)
References: <199702040556.WAA07410@branagh.ta52.lanl.gov>
	<m2pvyh9jnr.fsf@altair.xemacs.org>
	<199702042037.NAA12497@branagh.ta52.lanl.gov>
	<199702042147.OAA14285@branagh.ta52.lanl.gov>
	<kig3evcgq5g.fsf@jagor.srce.hr>
	<QQcbmr03409.199702042316@crystal.WonderWorks.COM>
	<kigpvygdsqo.fsf@jagor.srce.hr>
	<QQcbmz04998.199702050116@crystal.WonderWorks.COM>
Reply-To: bwarsaw@python.org
X-Attribution: BAW
X-Oblique-Strategy: Abandon normal instruments
X-WWW-Homepage: http://www.python.org/~bwarsaw


I seem to remember having very similar discussions on the Fvwm mailing
list, not long ago.  The question was slightly different, but I think
many of the issues were the same.  I re-checked my reference materials
to be sure I was getting the quotes right, though I have only old
(circa R4) X reference material here at home.

Section 10.2.1.4.2 of ORA's Xlib Vol 1 describes four input models.
For the sake of brevity I'll say that I believe XEmacs should (well,
at least can) adhere to the "Locally Active Input" model:

    "The client expects keyboard input and explicitly sets the
    keyboard focus but only does so when one of its windows already
    has the focus"

The section goes on to say that this model works for either
pointer-focus or click-to-focus WM preferences.  Imagine my WM is set
up to use pointer-focus and my pointer is in a lone XEmacs frame (say
the initial one).  Via keystrokes I tell XEmacs to create a new frame.
My understanding of this input model says that XEmacs can divert
keyboard focus to this new frame via a call to XSetInputFocus
(probably with revert_to set to RevertToParent).  At this point I
would expect the cursor in the original frame to turn hollow and the
cursor in the new frame to turn solid.  If my WM is operating
correctly, I would expect my original frame's decoration to indicate
it no longer has keyboard focus and the new frame to indicate it has
keyboard focus.  The new frame will now receive all keyboard input.

Now I type another keystroke which invokes other-frame.  At this point
I expect keyboard focus to return to the original window -- its cursor
turns solid while the new frame's cursor turns hollow.  My properly
operating WM obliges by changing the new frame's decoration to
I-dont-have-focus, while the original frame is turned to I-have-focus.

All legal and above board AFAICT.  In fact, I would expect exactly the
same behavior if my WM was configured in click-to-focus mode.  And it
is important to understand that no pointer warpage is necessary or
should be required.  Pointer warpage is Evil.

Now, its possible not every user will want XEmacs to adhere to the
Locally Active Input model.  Fine, there should be a user variable to
allow them to control this behavior.  I think this is what
focus-follows-mouse was a misguided attempt at.  I think these people
want XEmacs to adhere to the "Passive Input" model, a perfectly valid
desire:

    "The client expects keyboard input but never explicitly sets the
    keyboard focus."

Thus, I would suggest removing focus-follows-mouse variable since it's
inaccurately named, and adding a new one called keyboard-focus-model,
which has two legal values: 'passive and 'locally-active.  Either can
be the default although I'd argue that 'locally-active is the most
useful.

I'll respond to other individual messages separately, but I wanted to
lay down my basis for those response.  It is my understanding that the
behavior I want is both legal and possible, without requiring pointer
warpage.  I believe this because I have implemented such policy in
Grail 0.3 [*], which is based on Tk.

And yes I'm religious about this!  But you can challenge my faith if
you dare. :-) Seriously, we can argue details, but I really want to
know if anybody disagrees with the principles laid out here.  If so,
I can only take you seriously if you include chapter and verse!
(i.e. references :-)

-Barry

[*] In case anyone is interested, this stuff is not in Grail 0.3b2.
It will be part of beta 3, which should be released RSN.  See
http://grail.cnri.reston.va.us/ for details.

