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

[Steve Northover <Steve_Northover@xxxxxxxxxx>]

Ok, but there are no threads in the
browser so we don't really want API that talks about them.  For example,
Thread.start() can't be implemented.  How about Display.run(Runnable)
instead?  I guess the problem there is that Display nees to be created
before you can call run().  Of course it could be a static method.

What are MIDP application supposed to
do in main()?  For e4 on an embedded device, I imagine Display.run()
could behave like the browser (ie. do nothing and return right away).

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

04/11/2008 08:02 AM

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

With MIDP the event loops and threads are not visible
to the
applications, MIDP was designed on the days where the devices did not
have ´real threads. What I am imagining for SWT on E4 is a way to hide
the threads and event loop from the applications. Display.run() is one
step of that, I think the other would be to give the managed runtimes
the ability to give the thread to be used for the Display creation.

What would work for us is something like this.

/**
* Returns the thread that is safe to be used for UI operations.
* Some platforms restrict the threads that can be used for UI
operations, this method provides access to
* the correct thread to be used. The returned thread is guaranteed to
never be the same thread that the call is made from.
* If the calling thread already is the correct platform UI thread then
this method fails.
**/
public static Thread Display.getUIThread(Runnable UILoop)

Example:

Runnable UILoop = new Runnable() {
                
public void run() {
                
                 Display
display = new Display();
                
                 Shell
shell = new Shell(display);
                shell.open()
                display.run();
                
}
};

Thread UIThread = Display.getUIThread(UILoop);
UIThread.start();

--
Gorkem


On Wed, Apr 9, 2008 at 12:25 AM, Steve Northover
<Steve_Northover@xxxxxxxxxx> wrote:
>
> 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
>
>
> _______________________________________________
>  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