From xemacs-m  Mon Feb 10 10:09:34 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 KAA10978
	for <xemacs-beta@xemacs.org>; Mon, 10 Feb 1997 10:09:33 -0600 (CST)
Received: from newcnri.cnri.reston.va.us by CNRI.Reston.VA.US id aa12862;
          10 Feb 97 11:02 EST
Received: from anthem.CNRI.Reston.Va.US by newcnri.CNRI.Reston.Va.US (SMI-8.6/SMI-SVR4)
	id LAA04655; Mon, 10 Feb 1997 11:02:57 -0500
Received: by anthem.CNRI.Reston.Va.US (SMI-8.6/SMI-SVR4)
	id LAA00725; Mon, 10 Feb 1997 11:02:57 -0500
Date: Mon, 10 Feb 1997 11:02:57 -0500
Message-Id: <199702101602.LAA00725@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: Martin Buchholz <mrb@eng.sun.com>
Cc: Steven L Baur <steve@miranova.com>, xemacs-beta@xemacs.org
Subject: Re: Name of `focus-follows-mouse'
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>
	<199702042247.RAA21204@anthem.CNRI.Reston.Va.US>
	<m2iv48f3k9.fsf@altair.xemacs.org>
	<199702050503.AAA26671@anthem.CNRI.Reston.Va.US>
	<kigg1zbboex.fsf_-_@jagor.srce.hr>
	<m29152aipo.fsf@altair.xemacs.org>
	<199702060058.TAA27784@anthem.CNRI.Reston.Va.US>
	<199702100101.RAA23574@xemacs.eng.sun.com>
Reply-To: bwarsaw@python.org
X-Attribution: BAW
X-Oblique-Strategy: Concentrate on the very end
X-WWW-Homepage: http://www.python.org/~bwarsaw


>>>>> "MB" == Martin Buchholz <mrb@eng.sun.com> writes:

>>>>> "BAW" == Barry A Warsaw <bwarsaw@CNRI.Reston.VA.US> writes:

    BAW> I still like keyboard-focus-model, with values 'passive and
    BAW> 'locally-active.  But if you want to use a simple t or nil
    BAW> value, you might call it input-model-is-locally-active.
    BAW> Reverse the sense if you think passive would be more
    BAW> common. :-)

    MB> Since there will in general be multiple desired
    MB> keyboard-focus-models, I agree we should have one variable
    MB> with many possible values.

I disagree.  Let's start thinking about this by looking at what X
says.  First, there are four input models: No Input, Passive, Locally
Active, and Globally Active.  No Input model says that the "client
(application) never expects keyboard input" and so obviously is not
useful for XEmacs.  I claim that Globally Active is also not
appropriate since it says that the "client expects keyboard input and
explicitly sets the input focus, even when it is in windows the client
does not own."  Why would XEmacs ever set the focus to a window it
doesn't own?

I've already described the Passive and Locally Active models, both of
which are appropriate for XEmacs.  The basic difference is that in
Passive mode, the client never explicitly sets focus.  The window
manager must do it, which is why Martin would want the pointer to warp
when using Passive mode.  Under Passive mode, XEmacs can't set the
focus to a different top level window it owns, so either the new
window does not get focus, or XEmacs warps the pointer so that the
WM sets focus to that window.  In Locally Active mode, no pointer
warping is necessary since XEmacs is free to set focus to any window
it owns and window managers must do the right thing.

The user should be able to choose which model XEmacs operates under.
I think we all agree on this.

    MB> Personally I prefer to have user-initiated frame-selection
    MB> functions warp the mouse, which everyone else apparently
    MB> hates.  To me the reasoning is obvious:

    MB> With focus-follows-mouse, consistency demands that the mouse
    MB> pointer is always in the active X window.  Equally obvious is
    MB> that functions like (find-file-other-frame) should set
    MB> keyboard focus to the frame containing the visited file.  The
    MB> only way to achieve both these eminently reasonable wishes is
    MB> to warp the mouse to the newly selected frame.  I've run my
    MB> XEmacs this way for years.  XEmacs never warps the mouse on me
    MB> unexpectedly, since only user-initiated "go-to" command events
    MB> cause warpage.

If you truly want XEmacs to warp your pointer, which (my admittedly
old copy of) the ICCCM says clients should never do, then XEmacs
should only ever do this if it is in Passive input mode.  It is never
required in Locally Active mode, and I would claim that anybody who
explicitly uses this mode does so because they want focus to act
sanely without pointer warping.

Under Locally Active mode, the pointer does not need to be in the
focussed window for it to have focus.  It is enough that the pointer
is in one of the windows that XEmacs owns.  I can't really understand
why one would want to use Passive mode, but have pointer warpage to
keep the focus in the window.  But I suppose I can accept that there
are a significant number of users who want this warped (sorry :-)
behavior.  This says to me that the second variable we've talked about
ought to be `pointer-is-warpable' with values t and nil.

So my .emacs:

    (setq input-model-is-locally-active t)
    (setq pointer-is-warpable nil)   ; should be unneccesary!

And Martin's:

    (setq input-model-is-locally-active nil)
    (setq pointer-is-warpable t)     ; this *is* necessary

-Barry

