Closed
Bug 342691
Opened 18 years ago
Closed 12 years ago
unable to initialize gtk if embedding with javaxpcom/xulrunner
Categories
(Core Graveyard :: Java to XPCOM Bridge, defect)
Tracking
(Not tracked)
RESOLVED
INCOMPLETE
People
(Reporter: michal.ceresna, Assigned: jhpedemonte)
Details
Attachments
(2 obsolete files)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.4) Gecko/20060614 Fedora/1.5.0.4-1.2.fc5 Firefox/1.5.0.4 pango-text
Build Identifier:
I've tried to start XUL application from JavaXPCOM as described in
http://developer.mozilla.org/en/docs/JavaXPCOM:Embedding_Mozilla_in_a_Java_Application_using_JavaXPCOM#Working_with_XPCOM_objects
Mozilla moz = Mozilla.getInstance();
nsIServiceManager serviceManager = moz.getServiceManager();
nsIAppStartup appStartup = (nsIAppStartup)serviceManager.getServiceByContractID("@mozilla.org/toolkit/app-startup;1", nsIAppStartup.NS_IAPPSTARTUP_IID);
nsIWindowCreator windowCreator = (nsIWindowCreator)appStartup.queryInterface(nsIWindowCreator.NS_IWINDOWCREATOR_IID);
nsIWindowWatcher windowWatcher = (nsIWindowWatcher)serviceManager.getServiceByContractID("@mozilla.org/embedcomp/window-watcher;1", nsIWindowWatcher.NS_IWINDOWWATCHER_IID);
windowWatcher.setWindowCreator(windowCreator);
nsIDOMWindow win = windowWatcher.openWindow(null, "chrome://your-app/content/window.xul", "mywindow", "chrome,resizable,centerscreen", null);
windowWatcher.setActiveWindow(win);
appStartup.run();
The code above crashes on Linux. (I guess it works fine on win32).
The problem is that gtk_init() is on Linux/GTK called in the XRE_main function
which is not available from javaxpcom, and thus never called in the code above.
Initializing the gtk indirectly, e.g. creating some SWT widget before workarounds the crash.
What would be the best way of exposing the functionality for initializing the toolkit library from java?
Should that be handled via XRE api, javaxpcom api or untreated?
Reproducible: Always
Comment 1•18 years ago
|
||
The embedding application is responsible for initializing the widget toolkit (obviously XRE_InitEmbedding does not have access to argv/argc to call gtk_init(). I don't know whether the java embedding layer wants to special-case this somehow or leave it up to the individual application.
Assignee | ||
Comment 2•18 years ago
|
||
Interesting. I guess I never ran into this since I ran my testcases from within Eclipse, and that would have already run gtk_init().
For a full Java app that has no platform dependencies (i.e. non-SWT), the developer would expect initEmbedding() to handle all of this. Of course, as bsmedberg points out, initEmbedding() does not have access to argv/argc.
On the other hand, requiring the developer to call a GTK-only helper method before calling initEmbedding() seems wrong. I think I'd be more partial to changing initEmbedding() to call gtk_init().
Reporter | ||
Comment 3•18 years ago
|
||
This patch makes available the method XRE_main to Java embedders.
It allows to correctly start XUL application from java. See the attached
testcase which launches ChatZilla.
The code from
http://developer.mozilla.org/en/docs/JavaXPCOM:Embedding_Mozilla_in_a_Java_Application_using_JavaXPCOM
does not worl if the XUL application provides own components or extensions.
Note, that the XRE_main method itself initializes XPCOM, so I had to add
some help methods (initJavaXPCOM, shutdownJavaXPCOM) to initialize only
the javaXPCOM layer.
Comment 4•18 years ago
|
||
That's a different issue and should be in a different bug... running XRE_main from Java is "interesting", but I'm not convinced how useful it is in the real world, since XRE_main is synchronous and Java wouldn't have control of the eventloop.
Reporter | ||
Comment 5•18 years ago
|
||
How to test:
1)Download chatzilla XUL app from http://developer.mozilla.org/en/docs/XULRunner_Hall_of_Fame
2)unzip chatzilla-0.9.74-xr.zip
3)make sure, no other XULrunner without the xre_main patch is registred
4)update paths in Test2.java, and start
ChatZilla window should appear
Comment 6•18 years ago
|
||
Please file a separate bug for this.
I don't see how this is more useful than just finding xulrunner and then running "xulrunner.exe path/to/chatzilla/application.ini"
Reporter | ||
Comment 7•18 years ago
|
||
(In reply to comment #4)
> That's a different issue and should be in a different bug... running XRE_main
> from Java is "interesting", but I'm not convinced how useful it is in the real
> world
This is the scenario I use it for:
An XUL application which operates as slave for my Java application.
The application has a JS (IDL) component which serves as a gateway and
is I access it via Java interface thanks to javaxpcom.
I send there commands such as "load", "openTab" etc. and once loaded
I receive back nsIDOMDocument(s) which are used for further processing.
> since XRE_main is synchronous and Java wouldn't have control of the
> eventloop.
ATM, I use thread proxy (nsIProxyObjectManager).
Other option could be e.g. to add new GSource* into gtk event loop.
Reporter | ||
Comment 8•18 years ago
|
||
> I receive back nsIDOMDocument(s) which are used for further processing.
processing of the nsIDOMDocument(s) is quite intensive, I'm running some machine learning (ML) algorithms on it. Therefore, I need to run mozilla in-process.
The computation works as a smart crawler doing something similiar as:
load document
(ML processing)
choose link to follow
(ML processing)
return back
(ML processing)
choose other link to follow
Reporter | ||
Comment 9•18 years ago
|
||
discussion of the XRE_main patch continues in bug 343039
Reporter | ||
Updated•18 years ago
|
Attachment #227451 -
Attachment is obsolete: true
Reporter | ||
Updated•18 years ago
|
Attachment #227452 -
Attachment is obsolete: true
Status: UNCONFIRMED → RESOLVED
Closed: 12 years ago
Resolution: --- → INCOMPLETE
Whiteboard: closeme INCO 2012-09-01
Updated•10 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•