[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipse-incubator-e4-dev] SWT thread in managed runtimes
|
> Since there are no threads on the web...
If that's true, what does this mean:
"...the founders of Ajaxian.com discuss the latest developments,
including multithreaded JavaScript technology-powered UIs..."
(From that Google conference I mentioned earlier.)
McQ.
Steve
Northover/Ottawa/
IBM@IBMCA To
Sent by: E4 developer list
eclipse-incubator <eclipse-incubator-e4-dev@eclipse.o
-e4-dev-bounces@e rg>
clipse.org cc
Subject
04/08/08 11:43 AM Re: [eclipse-incubator-e4-dev] SWT
thread in managed runtimes
Please respond to
E4 developer list
<eclipse-incubato
r-e4-dev@eclipse.
org>
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@ To
eclipse.org "E4 developer list"
<eclipse-incubator-e4-dev@ecli
pse.org>
04/08/2008 08:31 AM cc
Subject
Please respond to [eclipse-incubator-e4-dev] SWT
E4 developer list thread in managed runtimes
<eclipse-incubator-e4-dev@eclips
e.org>
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
