Re: [platform-swt-dev] Request to get new SWT-API

[Stephan Aßmus <superstippi@xxxxxx>]

Hi,

On 21.01.2014 17:19, Ralf Sternberg wrote:
> I understand that blocking calls are a bit more convenient, but they are
> an exception to the programming model of SWT where, once the initial UI
> is created, all UI code is in event listeners that are called
> asynchronously. And (even though this point doesn't count for SWT's
> threading model) in the light of a computing world that involves more
> and more concurrency, shouldn’t asynchronous operations be considered
> more favorable than blocking ones anyway?

You might be confusing two concepts here. One is asynchronous operations 
that happen independent from the UI thread's program flow. The other is 
blocking dialogs where the program flow may be much easier to grasp when 
it actually continues after results from a modal dialog are obtained. 
That's because you would have assembled state in your call stack that 
would lost again, or would need to work entirely different, if you pick 
up where you left via a close notifaction.

That being said, it can be very confusing when things can happen in the 
blocking event loop, that are actually not anticipated right then. 
Consider for example another thread popping up a dialog in the UI thread 
by using Display.asyncExec(), which is then actually run in the event 
loop of the blocking dialog. This can cause a seemingly locked up UI 
which is just caused by how the shell flags make it impossible for the 
user to activate one of the competing dialog shells to even click a 
button. In my application I solved that by enqueuing such asynchronous 
Runnables in their own queue, which is only executed in the "real main" 
event queue.

Best regards,
-Stephan