On 08/22/2011 04:56 AM, Jeremy Huddleston wrote:
>> In particular, the above event comes from (or through) the
>> X11-server (it doesn't matter if it originates from OSX or not),
>> contains a 'window' field, asks some window e.g. to be 'closed', and
>> then the 'None' window is specified.
>
> No, you're missing the point. The server is not asking a known window to be closed. It's asking for the "front" window to be closed, and the WM is responsible for knowing this.
Having checked, neither ICCCM nor EWMH specifications talk about a
concept of a "front window", so it may be something related to
policies and preferences implemented by some particular GUI-desktop
environments?
I believe "front window" is actually the Apple concept; the notion of a non-frontmost window having focus is foreign to the Apple frameworks, so "focus" and "front window" mean the same thing. It maps directly to the X11 concept of focused window.
In other words, don't get lost in the terminology, just use the focused window and have done.
Looking at the above picture and therefore not knowing any better,
the most obvious reaction would be to close a window with ID 'None'
as specified by the X-event, much the same we always respect
window-IDs in X-events in all situations without exceptions. :-)
There is no such thing. And the X server usually treats drawable ID None as a reference to the root window of the default screen, which you really don't want to touch.
If you really can't map the event to a focused window, discard it (possibly raising an error).
It is controversial if an X11-WM should react to events of a
particular OS at all. In particular, twm is X-window manager by
design and has to react to X-events instead. OSX or any other OS on
the other hand could map its requests and duties through X-server
onto 'non-conflicting' X-event sequences and there is no problem for
twm or any other WM to operate appropriately.
Well, yes. That would be the point of the code you are operating on.
Why is it part of the WM, then, and not the server? Because per the ICCCM window management functions should not be hardcoded into the server but part of the window manager. The ICCCM isn't aware of the complexities of mapping events when the X server is actually a protocol transducer for a window system with an incompatible event model, so it ends up forcing the WM to be aware of such issues. I fully expect this to bite X11 emulation under Wayland as well, although in that case the most probable long term solution is that users will use desktop environments whose window managers will have both native and X11 components which communicate with each other. That would be the part you're operating on now, with the native component instead being the OS X services framework.