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

Yeah, not sure what kind of value you’d expect to pass that way.

And at this point I’m very hesitant to look at GPL code to make sure I
don't leak it into the port ;).

Doug.

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

>This rval looks bogus to me - how should that work when the enter
>returns the exit already
>has to be called - else you'd still block - see how Stage.showAndWait is
>implemented!
>
>Tom
>
>On 05.02.14 22:29, Doug Schaefer wrote:
>> 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
>> 
>> _______________________________________________
>> 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