Browsers are arguably the single most important application in the modern computing. There are many reasons why all major modern UI toolkits provide an integration with one (or several). There are many reasons to use browser in Eclipse RCP or IDE application:
- Use it to display static information with rich formatting (i.e. API doc, query result)
- Use it to integrate rich web application – either by creating a site-specific browser that connects to a remote server or by serving the application from your Eclipse instance.
- To provide better tools for web developers – integrating browser will let you better understand application runtime state and will allow you better explain to user the result of modifications.
SWT has a browser integration for a long time. Actually it has several integrations:
- Default System Browser. That’s what you get when you use the org.eclipse.swt.browser.Browser class (without specifying the “MOZILLA” style). This is by far the most stable integration that would cause you the least integration problems. It will wrap OS default browser (IE on Windows, Firefox on Linux and Webkit (Safari) on Mac OS X) – not that it will wrap the OS-default browser, not the browser that the user chose as a default. The biggest issue is that on Windows it turns into pumpkin IE – and you have no control over actual IE version it would become. So you will likely need to avoid some advanced features (including HTML5) and really invest a lot to ensure cross-platform compatibility of your web app code. Another issue is that there is little control over some more advanced browser features – i.e. as an IDE developer you may need to change the security configuration and that is not possible in a unified cross-platform way. Oh, and “default browser” might not be available on some Linux setups (at least that was a case a few years ago).
- XULRunner (Mozilla Firefox). This support is baked into SWT (see this snippet) and is triggered by specifying SWT.MOZILLA as a browser style. This browser provides a uniform cross-platform rich web experience but it still has a few shortcomings. First of all, it requires the browser to be installed separately. It will try to use the Firefox from the user OS and that means that you would have little control over the Firefox version – and this is exaggerated by the fact that some newer Firefox versions may break compatibility with older SWT versions and thus force the users to update their SWT-based applications. There are also some pretty irritating issues around integration edges (i.e. FF may grab input focus when you try to refresh it). There is a way to bundle XULRunner with your application if you create your custom bundle or use the one Zend created for ATF project.
- WebKit integration. This one gets more and traction as the WebKit is probably the most designed-for-embedding browser engine. SWT uses WebKit on Mac by default and support on GTK was introduced in SWT 3.6. Support for Webkit on Windows is planned for SWT 3.7. I have not tried it yet but it looks like there still will be a problem with the distribution as WebKit has some core components licensed under LGPL, which makes it impossible to be published on Eclipse.org.
- WebKit4SWT from Genuitec. This integration is Windows-only. As far as I understand, it is based on Chromium Embedding Framework so there is a chance that it will be available on other platforms when the upstream project adds those platforms (Valve used same framework for their Steam client and had published Mac source code – but it is not yet integrated into the upstream project). This project is used for Genuitec MobiOne project.