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

[Doug Schaefer <dschaefer@xxxxxxx>]

+1 I¹ve seen this happen and it is very confusing.

No, I still believe we need to eliminate the client driven event loops all
together. I can see where RAP and JavaFX would be similar in this. I don¹t
have a good answer of what to do now though other than mark
readAndDispatch and sleep as deprecated and document suggestions of what
to do instead.

Doug.

On 1/21/2014, 11:31 AM, "Stephan Aßmus" <superstippi@xxxxxx> wrote:

>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
>
>_______________________________________________
>platform-swt-dev mailing list
>platform-swt-dev@xxxxxxxxxxx
>https://dev.eclipse.org/mailman/listinfo/platform-swt-dev