[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[atf-dev] Re: atf-dev Digest, Vol 3, Issue 3
|
The problem in essence is that we use XPCOM to talk to the browser and
the underlying JSD API. XPCOM assumes you're in the same process;
there is no distributed-XPCOM, nor am I sure I want one :-)
I assume from your comments that EclipseXUL launches Mozilla as a
separate process? (Do they really use xulrunner? Do they
embed it in Java or some other executable?) In order to talk to
that external instance of xulrunner, we'd need to use some interprocess
communication mechanism. Javier Pedemonte has proposed using a
Java component loader such that the external instance of Mozilla would
launch a small Java process within it, and then you could talk to it
over RMI. He went further to suggest wrapping RMI around his
XPCOM bridge so this could be relatively transparent.
Another approach might be to get the embedded browser (xulrunner) to be
more chrome- and XUL- aware. xulrunner doesn't seem to be able to
do this by default, but bsmedberg implied that it ought to be possible,
perhaps a matter of configuration? I don't understand the details.
Regards,
Adam
On 6/16/06, "Lian Liming" <
lianliming@xxxxxxxxx>
As we know, most of the XUL applications has chrome manifest.
Single XUL page normally couldn't run as standard web pages. So load them
into embedded web browser directly seems unworkable.
Now in the EclipseXUL, it uses external XULRunner to launch the XUL
applications just like we launch them under command line. So the problem now
is that, as Adam said the runtime tools provided by ATF are tied directly to
our own instance of the Mozilla browser, if we don't use this mozilla
browser but external XULRunner to lauch XUL application, it seems very hard
leverage those runtime tools. Is it right?
