On Tue, 18 Apr 2000, Stefan Seefeld wrote:
> Well, from a practical point of view, how would I manage multiple input
> queues ? Given a list of visuals (as you seem to suggest) acting as window,
> I'd be forced into one thread per visual if I want to listen for events.
I had such a problem with OpenAmulet - and rearchitected LibGWT to a
simple scheme to solve it.
Basically, the main design is the following:
- real input events (those from the user) come from the root window and
the application gets them THERE. The application may block on such
waiting.
- expose events, or internally dispatched events can come from any
window event queue (I maintain a window list): they are polled.
I am NOT sure at all this behavior is The Right Thing to do, but I spent a
lot of time trying many solutions (except multithreading) and finally
switched to this simple solution because every other solution gave me
either a headache or horrible performance...
Just my 0.02
Rodolphe
