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