[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Short event-handling question...

From: Roman Kennke
Subject: Re: Short event-handling question...
Date: Thu, 13 Oct 2005 09:56:43 +0200

Hi Clemens,

> > 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?

The mapping from screen location to the actual component is done
somewhere in the peers (ComponentPeer). The peer then creates a
MouseEvent with the source set to the component that is located at this
position and posts that event to the event queue. The eventqueue then
calls dispatchEvent() on the source component.

> > 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 ;-)

Very interesting project indeed. Do you expect to use GNU Classpath for
the implementation? :-)


Attachment: signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

reply via email to

[Prev in Thread] Current Thread [Next in Thread]