Home » Eclipse Projects » Standard Widget Toolkit (SWT) » Backport Firefox 24 integration to 3.X
| | | | | |
Re: Backport Firefox 24 integration to 3.X [message #1235164 is a reply to message #1231343] |
Thu, 23 January 2014 17:46 |
Grant Gayed Messages: 2150 Registered: July 2009 |
Senior Member |
|
|
Hi, sorry for the late response,
SWT has a tool that parses XPCOM header files and generates the
corresponding nsI*.java files and XPCOM.VtblCall(...) native function
definitions (works for most header files). You can get the tool at
http://git.eclipse.org/c/platform/eclipse.platform.swt.git/tree/bundles/org.eclipse.swt.tools/Mozilla%20Generation/org/eclipse/swt/tools/internal/MozillaGenerator.java
.. To use it just set the GECKO, TARGET_FOLDER and XPCOM_HEADERS values
in its source appropriately.
For each generated nsI*.java class I would suggest deleting its function
calls that you do not use so that you can see if all of the required
XPCOM.VtblCall(...) function definitions are already there. Hopefully
they will be, because otherwise you will need to set up to re-compile
swt's xulrunner library on each of your supported platforms (this is a
different topic altogether). If you do need to add new
XPCOM.VtblCall(...) function definitions then you should have the SWT
Tools plug-in installed in your workspace, as it will detect them and
generate the corresponding JNI code in xpcom.cpp. To get the SWT Tools
plug-in go to Help > Install New Software..., Work with:
http://eclipse.org/swt/updates/4.4 .
If you have follow-up questions then CC me when responding to the
newsgroup, as I have not been here as much lately.
HTH,
Grant
On 1/14/2014 7:15 AM, Christian Sell wrote:
> Hello Grant,
>
> I have begun planning on the experiment of replacing the SWT version in
> our Eclipse 3.7-based application with the latest SWT which supports
> XULRunner >= 24. However, I am running into an issue that has been much
> discussed elsewhere: what to do with JavaXPCOM-dependent code. It turns
> out that our dependency is so deep that I'd rather reimplement the nsI*
> interfaces via JNI backed by native code than try to hack something
> together based on Javascript (that was my initial plan, not sure how
> realistic). Given that the SWT Mozilla integration seems to be doing
> just that internally, do you have any recommendations how to approach this?
>
> Thanks,
> Christian
|
|
|
Re: Backport Firefox 24 integration to 3.X [message #1240961 is a reply to message #1235164] |
Fri, 07 February 2014 09:15 |
Christian Sell Messages: 51 Registered: August 2010 |
Member |
|
|
Hello Grant,
thanks for the info, seems useful, indeed (hopefully it works, too). However, when running the generator over nsIDocShell.h and nsIDOMWindow.h, it fails with an ArrayIndexOutOfBoundsException. How about just copying those classes from the internal SWT packages?
And one more question:
when the tool is done generating the classes, it writes a number of lines to stdout, some of which contain "!ERROR UNKNOWN C TYPE" messages (see example below). Doesnt sound encouraging:
static final native int VtblCall(int fnNumber, int /*long*/ ppVtbl, !ERROR UNKNOWN C TYPE <bool >! arg0);
what does that error mean? What am I supposed to do with the list?
regards,
Christian
[Updated on: Fri, 07 February 2014 09:40] Report message to a moderator
|
|
| |
Re: Backport Firefox 24 integration to 3.X [message #1251514 is a reply to message #1241013] |
Thu, 20 February 2014 09:52 |
Christian Sell Messages: 51 Registered: August 2010 |
Member |
|
|
for the record: we have done as Thomas suggested, replacing the SWT bundles in our 3.7-based development target with the latest SWT bundles taken from 4.4M5. All seems to go well. We are bundling XULRunner 24. With regard to the missing JavaXPCOM classes, we have moved all uses of those classes behind a facade interface and then reimplemented that interface as a JNI/C DLL which interacts with native XPCOM. To do that, we needed access to the native address of the nsIWebBrowser object underlying the SWT Mozilla browser. Fortunately, there is a trick to obtain that address (which otherwise is hidden deep inside the internal SWT class structure): when you call Browser#getWebBrowser() on a Browser with SWT.MOZILLA style, SWT will try to find a class named org.mozilla.xpcom.Mozilla on the classpath. If one is found, an instance is created and the "wrapXPCOMObject(long address, String nsIID)" method is looked up and called. That method, as it turns out, is passed an address that can be safely cast to an (nsIWebBrowser *) on the C side! From there, everything else is a piece of cake!
My attempts to make use of the MozillaGenerator thingy failed - there were too many loose ends.
Heres a few more lessons learned so far:
- components are not registered automatically in XULRunner 24. You need to add code to interact with the nsIComponentRegistrar
- C or C++ code is well suited as a glue between Java and XPCOM. However, if you have more complex stuff to do (we have code that manipulates the DOM), Javascript is the way to go (according to Benjamin Smedberg, the master of XULRunner). In those cases, you will want to create a Javascript XPCOM component and call that via JNI/C
what remains for us is registration of plugins, which is also not the same as in XULRunner 10. Still investigating
|
|
| |
Goto Forum:
Current Time: Thu Sep 26 04:34:12 GMT 2024
Powered by FUDForum. Page generated in 0.04095 seconds
|