[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-swt-dev] Request to get new SWT-API
|
OK. Making my lambda comment was off topic for this list.
With regard to the API of non-exposed event-loop toolkits, instead of having a required DisposeListener, how about something simpler, like this:
DisposeEvent e = display.enterEventLoop();
I'm not sure what parameter, if any, makes sense for enterEventLoop(). And shouldn't its name be something like runEventLoop()? Or eventDispatch()? And maybe even return void?
Don
On Feb 5, 2014, at 4:18 PM, Tom Schindl <tom.schindl@xxxxxxxxxxxxxxx> wrote:
> a) who forces you to write a lambda?
> b) who forces you to use the proposed API? If you don't want to allow your code to run the javafx port stick with the event spinning
>
> As you might got from the comments an event loop is NOT exposed or exposeable on each ui toolkit.
>
> Tom
>
> Von meinem iPhone gesendet
>
>> Am 05.02.2014 um 23:47 schrieb Don Wills <don.wills@xxxxxxxxxxxxxxx>:
>>
>> Hello SWT developers,
>>
>> Lurker here. I'm a long time user of the SWT API for application code (non-plugin). I have two comments.
>>
>> First, I'm not a big fan of lambda expressions. I'm an old guy, so chalk up some of my dislike for distaste of any change. However, IMO, lambda expressions hide useful information, which equates to more problematic maintenance years from now by some newbie, and does not provide any new functionality.
>>
>> Second, it seems to me that the new code requires the application program to implement a DisposeListener, either implicitly (via syntax sugar), or explicitly (the way I would do it). Existing application code does not need to implement a DisposeListener, which is more elegant, IMO. I would prefer SWT syntax (API) like today's - it's easy to understand by beginning programmers, without sacrificing performance or readability.
>>
>> Don Wills
>>
>>
>>> On Feb 5, 2014, at 2: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
>
