[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipse-incubator-e4-dev] SWT thread in managed runtimes
|
The main() equivalent of MIDP is startApp() and by definition it is
called to indicate that the application has started but the problem
with startApp is it is mandated to return quickly(so it is not
possible to run the ui loop like in main()). eRCP wiki has a page that
explains the SWT/MIDP use.
http://wiki.eclipse.org/How_to_use_eSWT_with_Midlets
I think the static method that takes a runnable and runs the UI may
resolve the problem. This way implementation has all the possibility
to instantiate and start the SWT on the thread of her chosing.
Something like the following.
public static Thread Display.runUI (Runnable runnable)
--
Gorkem
On Fri, Apr 11, 2008 at 3:24 PM, Steve Northover
<Steve_Northover@xxxxxxxxxx> wrote:
>
> 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
>
>
> _______________________________________________
> eclipse-incubator-e4-dev mailing list
> eclipse-incubator-e4-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
>
>
