[mcclim-devel] X window manager focus

[Christophe Rhodes]

Hi,

Relatedly to my last message, I believe that there is another ICCCM
compliance issue in the CLX backend: this one is probably related to
window manager focus glitches.  Given a focus-follows-mouse setup, the
following occurs when I mouse into a McCLIM window:

  0: (CLIM-CLX::PORT-CLIENT-MESSAGE
      #<CLIM-INTERNALS::TOP-LEVEL-SHEET-PANE CLIM-INTERNALS::TOP-LEVEL-SHEET {1000671781}>
      NIL :WM_PROTOCOLS #(230 2313329802 7859248 7859248 2313329802))
    1: (CLIM-CLX::PORT-WM-PROTOCOLS-MESSAGE
        #<CLIM-INTERNALS::TOP-LEVEL-SHEET-PANE CLIM-INTERNALS::TOP-LEVEL-SHEET {1000671781}>
        NIL :WM_TAKE_FOCUS #(230 2313329802 7859248 7859248 2313329802))
    1: CLIM-CLX::PORT-WM-PROTOCOLS-MESSAGE returned NIL
  0: CLIM-CLX::PORT-CLIENT-MESSAGE returned NIL

where again the relevant part is that the timestamp passed down is NIL.

ICCCM has this to say (section 4.1.7):

  Clients that use a SetInputFocus request must set the time field to
  the timestamp of the event that caused them to make the
  attempt. This cannot be a FocusIn event because they do not have
  timestamps. Clients may also acquire the focus without a
  corresponding EnterNotify. Note that clients must not use
  CurrentTime in the time field.

so the call to XLIB:SET-INPUT-FOCUS in the PORT-WM-PROTOCOLS-MESSAGE
for :WM_TAKE_FOCUS (Backends/CLX/port.lisp) is doomed, at the moment,
to violate ICCCM.  However, if I'm reading this right, the
WM_TAKE_FOCUS client message has the timestamp we want to pass to
SET-INPUT-FOCUS in its data field somewhere:

  Windows with the atom WM_TAKE_FOCUS in their WM_PROTOCOLS property
  may receive a ClientMessage event from the window manager (as
  described in section 4.2.8) with WM_TAKE_FOCUS in its data[0] field
  and a valid timestamp (i.e. not CurrentTime) in its data[1]
  field. If they want the focus, they should respond with a
  SetInputFocus request with its window field set to the window of
  theirs that last had the input focus or to their default input
  window, and the time field set to the timestamp in the message. For
  further information, see section 4.2.7.

and indeed (elt data 1) in the above trace seems to be a valid
timestamp.

Am I on the right track, do people think?

Cheers,

Christophe