|
|
Re: How Much Concurrency Should be Exposed in a UI Toolkit?
|
Posted: Jun 19, 2007 8:16 PM
|
|
> > Please explain why you think this loop can't be in the
> > same thread as the application and still be
> > performed by the framework/toolkit rather than the
> > application itself.
>
> It could, indeed, be performed by the toolkit, but it
> wouldn't differ that much frm the SWT approach. You could
> do something like
>
> > JFrame f = new JFrame();
> ...
> Swing.runEDT(); // blocks until all frames are disposed or
> some other toolkit state change
>
>
> The method would block, because it runs in the main thread
> (if it didn't, it would be running in another thread,
> wouldn't it?). Basically, the same approach of SWT (a
> utility method would do the trick), but without the
> ability of controlling the loop directly.
>
> ... or I'm missing something? If events must be handled by
> the main thread, then you'll have to manage them yourself,
> or call the toolkit and wait until it finishes.
>
> Sorry, I'm the one who can't see how would you do to make
> the toolkit handle the event loop (something that Swing
> does, but in its own thread), without you having to do it,
> implicitly or explicitly (like SWT does), and without
> blocking the thread indefinitely.
Perhaps it depends on the definition of "implicitly". In .NET, GUI applications call the static method Application.Run to start their message loop, but the message loop code isn't written by the application developer. In addition, calling this Run method doesn't create a new thread, so it's truly single-threaded.
So my point was just that Swing could have been designed to do something similar to allow simple GUI apps to be single-threaded without giving up the power to use multiple threads in those cases where it was appropriate.
|
|
Previous Topic
