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 
Shell dispose events is only one trick that clients are using to terminate
event loops, and those cases are usually just dialogs. Looking at the few
loops in the Workbench, I see other things that are used to terminate
them. Being super flexible prevents us from getting locked in by a given
pattern. We can argue whether it’s the right name, but I think it makes
sense to stick with the JavaFX naming.

The big problem is that modern toolkits, such as JavaFX and Qt5 are
declarative. SWT was built for imperative kits. If we want to migrate our
plug-ins into this great new world and take advantage of hardware
acceleration and what have you in the new kits, we’re going have to change
how we program Eclipse UI. IMHO, at the end of the day, that means using
JavaFX directly and skipping over SWT. But baby steps first. Having a
great port that minimizes the wrinkles gets us where we need to go.

Doug.

On 2/5/2014, 6:49 PM, "Don Wills" <don.wills@xxxxxxxxxxxxxxx> wrote:

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

Back to the top