According to me email software Stefan Seefeld wrote:
| Andrew Apted wrote:
| > Personally, the idea of getting input "independently" of the output
| > doesn't feel right. The traditional "window" is a good abstraction,
| > it is a place to draw stuff for the user, and a place to receive the
| > feedback from the user.
| But you don't listen to a window for events. You listen to the server
| connection ('XDisplay') for events which *refer* to windows. A window -
| as it is seen by the application - is completely unaware of events.
The ability to listen to the display as a whole not just your own
window is a source of security problems (snooping/eavesdropping/...).
Of course if you can manipulate the event queue for more than your
window, you have kissed security goodbye.
[ Which is why X tags 'fake' events, but simply looking is frequently
too much. (cf "peeping toms") ]
| Ok, let's assume that windows listen themselfs for events. Then there
| are cases where you want to draw into some 'output only' medium, a
| Pixmap in X. Since Pixmaps and Windows in X are the same for the purpose
| of output (drawing), they are generalized to 'Drawables'. That's
| precisely what I'm asking for.
| To reiterate it once more: I can completely see your point of wanting to
| glue input and output together. Yet I think The individual entities for
| input and output should be accessible, even instantiable, through the
| public API. You should not to be forced to by an input context just
| because you need an output context.
Perhaps output 'structures' need to be generalised to deal with offscreen
bitmaps, but input should only be allowed in association with its "window".
- JonT
---
Jon Tidswell
Advanced OS Technology Group / Sawmill Linux Project
IBM TJ Watson Research Center 30 Saw Mill River Road, Hawthorne, N.Y. 10532
Email: [EMAIL PROTECTED] Voice: +1 914 784 7550
