Re: [platform-swt-dev] Request to get new SWT-API

[Tom Schindl <tom.schindl@xxxxxxxxxxxxxxx>]

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
>