X11 has two kinds of windows -- InputOnly and InputOutput. InputOnly windows receive mouse and keyboard events just like InputOutput windows but have no graphical content so that underlying windows show through them. InputOutput windows receive input and also occlude underlying windows.
Missing from this list is the notion of a window which occuludes underlying windows but is transparent to mouse position; an "OutputOnly" window if you will. Now you'll all asking yourselves "what good is an output only window?". Well, consider the drop shadows of Aqua -- those are essentially windows which appear above other windows for the purpose of graphical output but wihch don't affect mouse input. We can add alpha components to windows, but without some way to modify the mouse clipping behaviour, we can't provide this kind of interface. I went and prototyped OutputOnly windows in the server and discovered that they really weren't as useful as I'd like -- because the window is invisible for puposes of input, it wouldn't be semantically consistent to make decendent windows receive input. So, to implement drop shadows, you'd have to place OutputOnly windows only where the drop shadows appeared and not where the regular application window did. Dragging and resizing would involve the syncronized configuration of several windows, something which always makes things look clunky. As a replacement, I looked at the Shape extension and decided that a very easy thing to do would be to add another region to each window, the "input region" which would clip input but not output. Place an input region covering the application area but not the drop shadow and suddenly everything works just fine. Adding an input region to the Shape extension would require only very minor changes, in particular, the current bounding and clip regions are named in the requests which modify them so only a new name would be required meaning no new requests would be needed. The changes in the DIX level are similarly straightforward -- a new per-window (in the WindowOptional) structure paralleling the current shape regions would be added and then XYtoWindow would be modified to respect that region. Confining the mouse on grabs requires a bit more work, but nothing significant. Most notably, there would be no effect below the DIX level. This would be something added after 4.3, so there's no particular schedule to be concerned about here. Keith Packard XFree86 Core Team HP Cambridge Research Lab _______________________________________________ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
