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

Nice. And would a non JavaFX port implement it as wait/notify on the key?

Also the current toolkit API has an rvalue that is passed into exit call
which is then returned by the enter call. I’m not sure we really need that
in the port. Is that why you left it out?

I could probably update my SWT fork with these now and start making
changes in the workbench fork. That would certainly get us past this and
onto the paint listeners :)

Thanks Tom!
Doug.
    

On 2/5/2014, 4:21 PM, "Tom Schindl" <tom.schindl@xxxxxxxxxxxxxxx> wrote:

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


Back to the top