NetNews Usenet Archive 1992 #16/NN_1992_16.iso/spool/alt/lucidem/bug/64

Text File | 1992-07-28 | 3.7 KB | 76 lines

Newsgroups: alt.lucid-emacs.bug
Sender: [e-mail]
Date: Tue, 28 Jul 92 09:06:59 PDT
From: [e-mail] (Matthieu Devin)
Message-ID: <[e-mail]>
Subject: Re: lemacs is grabbing window focus when it isn't supposed to
References: <[e-mail]>
Path: sparky!uunet!wendy-fate.uu.net!bug-lucid-emacs
Lines: 65

Colas is wondering why Emacs takes the focus.  This is necessary to implement
select-screen: a lisp function that makes another Emacs screen be selected
meaning that the typed characters go to this screen.  The semantic of
select-screen is really to move the keyboard focus from one Emacs screen to the
other.

The advantage of setting the focus is that the WM can show you with some kind
of highlight where is the focus.  Otherwise you end-up with one Emacs screen
highlighted and the characters going into and other screen.  Confusion!

Explicitely taking the focus is the ICCCCCCCCCM way to do this.  It does not
work with bogus window managers, but it is supposed to work.  (At least in
our understanding of the ICCCM, if WM persons like Colas have a better
understanding please, please correct me).  By "does not work" I mean that
Emacs sometimes steals the focus after the user thought it moved it to
another window, like an xterm.  We beleive we are having all those problems
because Lucid Emacs seems to be the first large client to use WM_TAKE_FOCUS.

First, what the ICCCM says (in my own words):

  When a client as WM_TAKE_FOCUS set the WM has to send a WM_TAKE_FOCUS
  message to ask the client if it wants the keyboard.  This message has a
  timestamp in arg[1] (or 0?) which is most likely to be the timestamp of the
  XEvent that caused the WM to decide that Emacs could take the focus (an
  EnterWindow event, an explicit click in a title bar, etc.).

  The client has to answer by explicitely setting the focus to one of its
  windows, i.e. by calling XSetInputFocus with the timestamp passed in the
  event.  The timestamp is the key here, it is used to solve race conditions
  when the WM_TAKE_FOCUS client is too slow to answer, like Emacs can be when
  swapped out, garbage collecting, etc.  XSetInputFocus is defined as a noop
  if the timestamp is earlier than the timestamp of the last call to
  XSetInputFocus.

  For the timestamp to correctly solve the race condition problems a real
  estate driven WM has to explicitely set the Focus back to PointerRoot when
  the focus has to move from a WM_TAKE_FOCUS client to a non WM_TAKE_FOCUS
  client.

Example: in a real estate driven WM, the mouse goes from an xterm to Emacs to
an xterm again.  The WM sends WM_TAKE_FOCUS with time t1 to Emacs and
then do XSetInputFocus (t2, PointerRoot) for the xterm.  When Emacs wakes up
and answers the TAKE_FOCUS its call to XSetInputFocus is ignored because t1
is less than t2.  So Emacs does not steal the focus.

Now, the benefits:

  As Emacs is a WM_TAKE_FOCUS client it can explicitely switch the focus to
  any of its windows as long as it already has the focus when it does it and
  use valid timestamps in the call to XSetInputFocus (using CurrentTime here
  would clearly lose).

  The WM can track the focus changes and correctly highlight the focus
  window.  Some WM could even decide to raise the window if the user had said
  that the focus window should always be on top.

So unless I'm totally confused (which is extremely possible as ICCCM stuff is
really hard) Emacs is doing the right thing.  I know that most WM do not do
the right thing yet but my guess is that it's because they did not have test
cases for the full WM_TAKE_FOCUS stuff.  If we disable this feature the WM
will never be fixed.

Colas what do you think?  Can gwm do the right thing?

Matthieu