Once upon a time I wrote:
> | 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/...).
<...>
> Perhaps output 'structures' need to be generalised to deal with offscreen
> bitmaps,
> but input should only be allowed in association with its "window".
I believe Stefan Seefold responded:
| what do you mean with 'its' ? Do you mean that each offscreen bitmap
should
| have a "window" it is associated with ? This would be what X refers to as
| visual, i.e. a structure holding formatting info for pixels, colors etc.
An offscreen bitmap can't get input. :-)
[ Damn. I need to reread the GGI terminology. ]
When I say window, I mean something the user understands as a window, not
an internal data structure used for OO style GUI development.
I meant that input should _still_ be associated with a particular window,
even if output was generalised.
I see the problem in X/Win32/MacOS because the internal 'window'-list is
reused
as a user visible 'window'-list allowing applications to see 'windows' that
belong
to other applications.
And two different user-'windows' should not share event queues.
| Lots of windows can use the same visual. This makes my point since I'm
arguing
| that GGI's visual plays the role of all of them: drawawbles (which I
might want
| to have many), visuals (there might be a few) and event queues (generally
| one, at least in a single threaded application).
This has unfortunately wandered.
I was responding in the context of XDisplays, where X has multiple windows
from
multiple applications.
- JonT
