[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [platform-swt-dev] Request to get new SWT-API
|
most the of the event loops you see are this:
shell.open();
while(!shell.isDisposed()) {
if( !d.readAndDispatch() ) {
d.sleep();
}
}
and can could be rewritten with:
Object key = ....;
shell.addDisposeListener((e) -> d.exitEventLoop(key));
shell.open();
d.enterEventLoop(key);
On 05.02.14 22:12, Doug Schaefer wrote:
> Actually, that¹s a pretty good strategy anyway and good point by Steve.
> And +1 on these two additions. A couple of questions though.
>
> First, this currently isn¹t API. Are they confirming that it will be made
> API?
>
> Second, how would this replace the current event loops? The semantics are
> quite different. Do you have a suggestion on a new code pattern?
>
> Thanks!
> Doug.
>
>
> On 2/5/2014, 4:01 PM, "Tom Schindl" <tom.schindl@xxxxxxxxxxxxxxx> wrote:
>
>> Hi,
>>
>> I had the chance to chat with Steven Northover some days ago and talked
>> with him about the event loop spinning.
>>
>> Something fairly impossible to find out is FX is when the event loop is
>> IDLE but he raised a fair point - if requesting an API on SWT why not
>> really requesting the same API that is used in FX this way it is 100%
>> guaranteed that the API can be supported by a potential FX-Port.
>>
>> So the API on FX looks like this:
>> * Toolkit#enterNestedEventLoop(Object)
>> * Toolkit#exitNestedEventLoop(Object)
>>
>> which would translate in SWT to:
>> * Display.enterEventLoop(Object)
>> * Display.exitEventLoop(Object)
>>
>> Tom
>>
>> On 14.01.14 22:40, Tom Schindl wrote:
>>> Hi folks,
>>>
>>> I don't know if you are following my work on getting a new SWT-port
>>> which works on top of JavaFX bootstrapped.
>>>
>>> JavaFX does not expose the event loop so that one can implement
>>>
>>> while(<condition>) {
>>> if( d.readAndDispatch() ) {
>>> d.sleep();
>>> }
>>> }
>>>
>>> efficiently.
>>>
>>> The main use case for the above is to stop the control flow without
>>> blocking the event processing (probably the most common use case is
>>> opening a Shell and waiting until it is closed).
>>>
>>> My proposal would be to provide the following API:
>>>
>>> * Display
>>> Display#block(Condition)
>>>
>>> * Shell
>>> Display#openBlocking()
>>>
>>> The Shell API is not strictly needed but more a kind of convenience API
>>> for the most common use case.
>>>
>>> I've not yet filed a bug report but get in touch with the team to see if
>>> something like this is you would consider to add.
>>>
>>> Tom
>>> _______________________________________________
>>> platform-swt-dev mailing list
>>> platform-swt-dev@xxxxxxxxxxx
>>> https://dev.eclipse.org/mailman/listinfo/platform-swt-dev
>>>
>>
>> _______________________________________________
>> platform-swt-dev mailing list
>> platform-swt-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/platform-swt-dev
>
> _______________________________________________
> platform-swt-dev mailing list
> platform-swt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/platform-swt-dev
>