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