moving this to jbosstools-dev
> > ∙ Reproducing JBIDE-11592 - SIGSEGV when tried JBT
3.3.0.Beta2 on Juno;
> > ∙ Created prototype for eclipse<->browser communication on XULRunner
v>2/WebKit/IE - JBIDE-12276;
>
> Interesting - what kind of communication ? communication to external process ?
> It is Eclipse<->IE/WebKit/XulRunner>=4 communication via SWT Browser
widget.
> As you know, now VPE is implemented using JavaXPCOM interfaces to communicate with
XULRunner.
> But theoretically almost everything what we do now, could be implemented using
browser.execute() method to invoke JavaScript from Java, and BrowserFunction class to
invoke Java from JavaScript. This would make VPE browser independent and allow to support
the most recent browsers.
> So I just created a simple Eclipse editor using these two methods as a proof of
concept. This editor allows to change style of selected text from Eclipse toolbar.
It is considerably slower than JavaXPCOM bridge. Using Browser would simplify
implementation on Java side, but then we have to do JavaScript part and test it with all
browsers that could be Behind Browser.java class.
Doesn't sound fun (neither Speed nor QE tasks).
How big a speed difference are we talking about here? And when ?
Is it just when doing style changes or also when editing ? with webkit there is a more or
less native edit mode is there not ?
I'd rather spend time and ported JavaXPCOM bridge to latest
XulRunner build, because it was implemented as build extension and use code generation to
get all XPCOM Interfaces mapped in Java, so it looks doable.
XULRunner is going away/dying afaik I know - especially JavaXPCOM and its missing on
64-bit platforms especially. Considering this - is it worth spending time on that ?
Another option is look though what kind of functions VPE uses out of
JavaXPCOM and implement it for WebKit.
How feasible is this ?
/max