Re: [eclipse-incubator-e4-dev] SWT thread in managed runtimes

[Steve Northover <Steve_Northover@xxxxxxxxxx>]

Ok, we are talking about two different
things.

Somehow C programs work on mobile devices.
 I'm afraid I don't have all the details about MIDP but it sounds
like it is defined to be unfriendly to native widget toolkits.  Just
saying that a restriction is lifted won't really help here if it can't
be implemented (like on the Mac).  What do you suggest we do (other
than what OSGi has done already)?

"Gorkem Ercan" <gercan@xxxxxxx>
Sent by: eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx

04/08/2008 05:09 PM

Please respond to
E4 developer list <eclipse-incubator-e4-dev@xxxxxxxxxxx>

To	"E4 developer list" <eclipse-incubator-e4-dev@xxxxxxxxxxx>
cc
Subject	Re: [eclipse-incubator-e4-dev] SWT thread in managed runtimes

The need for the thread actually comes from the mobile
device
runtimes. On devices we run SWT (eSWT) with eRCP and MIDP runtimes.
eRCP runtime is an easy case where the Display is created but the
runtime container but on MIDP Display creating is the responsability
of the applications and because of the way midlets work it requires
the application to create a thread for this purpose. If the underlying
toolkit presents a limitation I have described then creating and
running SWT UI thread on any thread becomes impossible.
Another problem is some toolkits have a restriction that they allow a
single toolkit initialization per process and they are usually bound
to a thread. if the runtime uses the native toolkit for some reason
(splash screen, error dialog etc), then Display must be able to reuse
the thread.
--
Gorkem

On Tue, Apr 8, 2008 at 6:43 PM, Steve Northover
<Steve_Northover@xxxxxxxxxx> wrote:
>
> Since there are no threads on the web (in Dojo, Flex or Silverlight),
I
> don't understand the problem.  I'm talking about running on the
client.  Are
> you on the server?
>
> Here is the problem that we face and (possibly) the source of the
rumour:
> "On the web, you can't wait."
>
> This means that Display.readAndDispatch() and other API in SWT that
waits is
> out.  Fortunately, there isn't much.  In the case of readAndDispatch(),
the
> thinking is to add Display.run() and Display.quit().  On the
desktop,
> Display.run() will do a read and dispatch loop until quit() is called
and
> then it will exit from main().  On the web, Display.run() is
a noop and will
> return immediately, possibly with a return code to allow smart applications
> to tell where they are running.  HelloWorld will look something
like this:
>
> public static void main(String[] args) {
>         Display display = new Display();
>         Shell shell = new Shell(display);
>         shell.open();
>         display.run();
> }
>
>
>
>
>
> "Gorkem Ercan" <gercan@xxxxxxx>
> Sent by: eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx
>
> 04/08/2008 08:31 AM
>
> Please respond to
>
>  E4 developer list <eclipse-incubator-e4-dev@xxxxxxxxxxx>
>
>
> To
> "E4 developer list" <eclipse-incubator-e4-dev@xxxxxxxxxxx>
>
> cc
>
>
> Subject [eclipse-incubator-e4-dev] SWT thread in managed runtimes
>
>
>
>
>
>
> Hi,
>  I heard rumors that there will be some changes in the way SWT
UI
>  thread is run in order to make it more compatible with the web
model.
>  Since I have not seen the discussion can anyone summarize what
is
>  discussed (or point me to the discussion).
>
>  The reason I am interested is, I am noticing a problem with
SWT UI
>  thread when it is used in a managed runtime container such as
Midlets
>  or any*lets. The problem comes from the fact that some native
UI
>  toolkits would like to use the first thread in the process to
be the
>  UI thread (I think Mac has that limitation). The managed runtimes
>  usually can reserve the first thread for the UI but there is
no way to
>  guarantee that the applications will use that thread to create
the SWT
>  thread. So what I would like to see is a way to retrieve the
preferred
>  thread SWT UI thread. It can be made so that any many platforms
thread
>  is not important and it would return any thread but this would
help
>  with those platforms with such limitations of UI threads.
>  --
>  Gorkem
>  _______________________________________________
>  eclipse-incubator-e4-dev mailing list
>  eclipse-incubator-e4-dev@xxxxxxxxxxx
>  https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
>
>
> _______________________________________________
>  eclipse-incubator-e4-dev mailing list
>  eclipse-incubator-e4-dev@xxxxxxxxxxx
>  https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
>
>
_______________________________________________
eclipse-incubator-e4-dev mailing list
eclipse-incubator-e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev