I've done a little testing, and found out that it is indeed the window manager getting in the way, intercepting Alt-F4 and sending a Quit event in its place. Unfortunately it's not particularly easy to work around this. Reading the keyboard state after getting the Quit event doesn't seem to work (although it works fine in all other cases). Setting up an event filter to mask the Quit event does work, but unfortunately that masks
all Quit events, making it impossible to close the window via the window manager at all. Setting a flag in the event filter upon Quit to handle it manually can get around that, but then the keyboard state doesn't work again. Argh.
There is another way to accomplish this, though. Grabbing the input makes (almost) all keyboard events bypass the window manager and go directly to the window. Unfortunately this also means confining the mouse to the window, which makes it rather unusable for our purposes. Well, unless I set up a system that grabs the input when the mouse enters the window and ungrabs it when it attempts to leave, so that we'd at least get the event when the mouse is in the window. Hm. I made a little test program, and this seems to work fine. It would be possible to add this to DROD, but this would also mean that any other WM hotkeys would not be handled correctly (unless we add code for those, if possible). For example, moving the window with ALT (or WIN/META/whatever) wouldn't work. I think this might be a bit too intrusive. Too bad we can't do selective grabbing .. (Hm, actually I think that could be arranged too, by ungrabbing on key-down and grabbing on key-up, and having a special case for ALT-dragging .. Resulting in layers upon layers of hacks ..
).
- Gerry