| Re: [platform-swt-dev] Request to get new SWT-API |
Hi,
I went ahead and created a bugzilla and a proposed an implementation for
the Mac-Port.
Tom
On 14.01.14 23:15, Tom Schindl wrote:
> Hi,
>
> Well the implementation is almost trivial for all current SWT ports:
>
> public void openBlocking() {
> Display d = getDisplay();
> while( ! isDisposed() ) {
> if( ! d.readAndDispatch() ) {
> d.sleep();
> }
> }
> }
>
> Anyways the really important API is the one on display because then one
> can implement blocking dialogs, so if the above API is provided blocking
> would look like:
>
> public void openBlocking() {
> Condition c = new Condition() {
> public boolean valid() {
> return ! isDisposed();
> }
> };
>
> getDisplay(c);
> }
>
>
> On your other questions:
>
> The initial stage provided by FX is not going to be used - I'm more
> convienced that we should in future launch JavaFX simply by calling
>
> PlatformImpl.startup(new Runnable() {
> @Override public void run() {
> // No need to do anything here
> }
> });
>
> but this is beyond the scope of the API requested and thread - I don't
> have headaches at the moment with the bootstrapping of FX because this
> is done only once so we'd only have to patch the start up code to get
> the workbench running.
>
> If there was christmas and I'm a small child I would have quested:
>
> Display.bootstrap(Callback<Display> c) as well ;-)
>
> If we get the API on Shell - the answer to your question is YES we would
> directly call the Stage.showAndWait API.
>
> Tom
>
> On 14.01.14 23:00, Doug Schaefer wrote:
>> Hey Tom,
>>
>> Can I assume that Shell.openBlocking() would call JavaFX¹s
>> Stage.showAndWait()? If that¹s the case, this is probably more than
>> convenience method.
>>
>> But the expense of adding API at this point is pretty high. You¹d have to
>> provide implementations and testing for all of the other ports since Shell
>> and Display aren¹t common.
>>
>> I haven¹t looked at too many examples, but for the modal dialog case, are
>> shell.open()¹s followed closely by an event loop? If that¹s the case the
>> open() call could register itself with Display so that the next call to
>> sleep would call showAndWait(). But that might not cover all the cases.
>>
>> The bigger issue I see is with the main event loop that apps generally
>> implement. If you end up calling them from the JavaFX Application.start()
>> implementation, the JavaFX event loop never starts up. And you can¹t call
>> showAndWait() on the primaryStage anyway. We can fix the Workbench to do
>> things properly, but I¹m not sure what the right answer is for plain SWT
>> apps.
>>
>> Doug.
>>
>>
>> On 1/14/2014, 4:40 PM, "Tom Schindl" <tom.schindl@xxxxxxxxxxxxxxx> 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