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 _______________________________________________ Classpath mailing list [email protected] http://lists.gnu.org/mailman/listinfo/classpath
