The Artima Developer Community
Sponsored Link

Weblogs Forum
How Much Concurrency Should be Exposed in a UI Toolkit?

34 replies on 3 pages. Most recent reply: Jun 21, 2007 8:41 AM by Achilleas Margaritis

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 34 replies on 3 pages [ « | 1 2 3 ]
Ronald Tetsuo Miura

Posts: 22
Nickname: ronaldtm
Registered: Jan, 2004

Re: How Much Concurrency Should be Exposed in a UI Toolkit? Posted: Jun 19, 2007 6:34 PM
Reply to this message Reply
Advertisement
> 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.

Jeff Ratcliff

Posts: 242
Nickname: jr1
Registered: Feb, 2006

Re: How Much Concurrency Should be Exposed in a UI Toolkit? Posted: Jun 19, 2007 8:16 PM
Reply to this message Reply
> > 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.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: How Much Concurrency Should be Exposed in a UI Toolkit? Posted: Jun 20, 2007 4:21 AM
Reply to this message Reply
> > It's obvious, really: no changes are needed in the
> Swing
> > threading model.
> >
> > I hope the above is not too difficult to digest :-).
>
> I think Sun made a poor design choice when they forced all
> Swing apps to be multithreaded by virtue of putting GUI
> events in a separate thread on startup. They could have
> started with everything in the same thread and then let
> the developer decide if there was a need to create worker
> threads.
>
> Having said that, I don't think they could realistically
> change the behavior now and Sun is opposed to any
> fundamental changes in Java anyway.

But Swing apps are effectively single threaded; No one does anything in function 'main' anyway other than setting up an event to setup the UI...

Jeff Ratcliff

Posts: 242
Nickname: jr1
Registered: Feb, 2006

Re: How Much Concurrency Should be Exposed in a UI Toolkit? Posted: Jun 20, 2007 7:56 AM
Reply to this message Reply
> But Swing apps are effectively single threaded; No one
> does anything in function 'main' anyway other than setting
> up an event to setup the UI...

I wouldn't want to make any claims about what everybody does or does not do, but if you're right, what's the point of the way it's designed? The only effect seems to be that everybody has to write boiler-plate code. Why not have main be in the same thread by default and be done with it?

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: How Much Concurrency Should be Exposed in a UI Toolkit? Posted: Jun 21, 2007 8:41 AM
Reply to this message Reply
> > But Swing apps are effectively single threaded; No one
> > does anything in function 'main' anyway other than
> setting
> > up an event to setup the UI...
>
> I wouldn't want to make any claims about what everybody
> does or does not do, but if you're right, what's the point
> of the way it's designed? The only effect seems to be that
> everybody has to write boiler-plate code. Why not have
> main be in the same thread by default and be done with it?

Because Swing designers originally thought that the GUI thread should be a 'worker' thread for the application, and not the main thread.

The truth is no other GUI library makes that assumption.

Flat View: This topic has 34 replies on 3 pages [ « | 1  2  3 ]
Topic: How Much Concurrency Should be Exposed in a UI Toolkit? Previous Topic   Next Topic Topic: New Python 3000 Video and Slides

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use