Re: Short event-handling question...

[Clemens Eisserer]

Hi Roman,


> AFAIK, this happens in java.awt.DefaultKeyboardFocusManager. I would
> think that your statement only is true for synthetic keyboard events.
Ahh, interresting - and it seems logically quite clear to me that its
in the Focus manager.

I have only tried it with Sun's java implementation, and I tried it
with mouse-events sending to a JFrame which also were delivered to the
widget at whose position the event happend.
Do you know where this is done?

> Whoa, crazy :-)
Hmm, more or less a makeshift, we already tried with java-based
x-servers but the performance is horrible and furthermore java does
not now howto handle more than 1 X display at a time.

> Maybe you can give a little more information, otherwise I can hardly
> imagine, what you want to implement. I mean, the client would reside
> inside a JFrame (?), and have it's own event queue and drawing
> mechanism. Where would the server intercept here?
The client would send only the events to the server where the whole
gui lives on a not-native JFrame which returns its own Graphics-class
via getGraphics which sends the drawing commands back to the client.
Of course there's a "little" bit more like image-handling/caching,
Fonts stuff etc but that could be done later.

My problem for now is that I do not understand whats going on under
the hood since a not-realized JFrame would not paint for example at a
repaint() call of course.
So the hardest part will be to tell all the managers
(RepaintManager/FocusManager/....) that they should work ;) - and
simulate the events which come from the client (should be doable with
getSystemEventQueue().postEvent) of Toolkit. Also great would be an
SystemEventQueue which uses a thread-pool (since many clients are
expected to be connected to the server) ... however that's another
topic ;-)

Thanks for answering, lg Clemens