Skip to main content

[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
> 



Back to the top