On most platforms Flash should work with WebRenderer Swing Edition if Flash has been set up to run in Firefox, as WebRenderer Swing Edition uses the plugin finder from the Mozilla engine to detect the Flash plugin. If Firefox is not setup with Flash on the target machine, the easiest way to enable Flash is to place the plugin into the WebRenderer profile directory located at:

<user home directory>/.webrendererswing6/<platform>/corecomponents/plugins

The Flash plugin file that is required depends on the platform. On Windows, the file name contains the Java architecture to be used (32 or 64-bit) and the Flash version number. Note that the file name specifies the architecture, regardless of the directory it is located in. The plugin file to use can be obtained from a system that has had Flash installed.

On a Windows 7 machine, the plugin files (for multiple architectures) are located at:
C:\Windows\SysWOW64\Macromed\Flash\NPSWF32_11_8_800_168.dll
C:\Windows\System32\Macromed\Flash\NPSWF64_11_8_800_168.dll

On Linux, the Flash plugin file is libflashplayer.so, and can be located by extracting the Flash download of the required architecture.

Repackaging WebRenderer to include Flash:
1- Extract the corecomponents-swing-xxx.jar (JAR files can be extracted the same as .zip files)
2- Add Flash or other plugin files to the corecomponents/plugins/ directory
3- Recreate the JAR file from the corecomponents/ directory, to replace the original corecomponents-swing-xxx.jar

The plugin should now be deployed when WebRenderer unpacks itself.

Please note; if you have already run WebRenderer then the corecomponents-swing-xxx.jar will not extract and run with your plugin, and you therefore have to force WebRenderer to extract these. This can be done by altering the versionxxx (“xxx” denotes the version number) and calling the BrowserFactory setCorecomponentsExtractOn method. Alternatively the .webrendererswing6 directory can be deleted from the target system entirely. This ensures that the latest components will be extracted.

It should be kept in mind that although third party plugins can be used with WebRenderer we cannot make any assurances regarding the quality of third party plugins or their interoperability with WebRenderer.

Related links:
Flash Player download – http://get2.adobe.com/flashplayer/otherversions/
Flash version check and test – http://www.adobe.com/software/flash/about/
Creating a JAR file – http://docs.oracle.com/javase/tutorial/deployment/jar/build.html

We thought we would put together an example that demonstrates some of the in-browser functionality. In this example we use WebRenderer Swing Edition to create a special “Zoom” effect when a click action is selected, like so:

The Zoom Browser demonstrates content being displayed on top of the Java browser in a glass pane. This content is an image taken from the browser itself and modified to give a scaled view. Click with the mouse scroll wheel to show. Scroll with the wheel, navigate to a new page or press ESC to remove the display.

How do we do this? When the click is made with the scroll wheel, a buffered image is created of the visible browser content using WebRenderer. The mouse cursor coordinates from the click are used to select a corresponding section of the buffered image. From here, the section is scaled (in this case double the size) and a new image is created of the section. This new image is drawn at the click position onto an overlay, which is used as a glass pane on top of the frame containing the browser.

As long as this sub-image exists, it will be drawn whenever the overlay is painted. Since scrolling or loading a new page would change the content, the sub-image is set to null, so that it will be removed from the overlay in these cases.

You can grab the source code for this here..
And for a free 30 day trial of WebRenderer Swing Edition, head over here..

Here is a screenshot:

MozillaBrowserCanvas browser = BrowserFactory.spawnMozilla();
browser.setPrefProperty("network.websocket.override-security-block", true);
browser.loadURL("http://www.websocket.org/echo.html");

All is not lost however. It is possible to launch an Applet in a way that will only download the relevant files for the target system. This is done through a JNLP file that is usually associated and used with Java Web Start programs. The JNLP deployment option for Applets was introduced in Java 1.6.0_10.

Details on using JNLP with Applets can be found at: http://www.oracle.com/technetwork/java/javase/index-142562.html

The following code is an example JNLP file that can be utilized to deploy an Applet with platform targeted libraries:

This JNLP file (webrenderer-applet.jnlp) specifies the WebRenderer libraries as resources under different Operating Systems and Architectures. Through this deployment specification only the files needed are downloaded to the target machine. For demonstration purposes WebRenderer is run from a simple program called TestBrowser (included with the WebRenderer download) and is specified at the end of the JNLP file above under “applet-desc”.

Enabling JNLP deployment for Applets requires an extra param tag to be added inside the Applet tag that refers to the JNLP file:

The architecture used on a particular platform by the Applet depends on the Java architecture that the browser is using. So on a 64-bit OS that is using 32-bit Java, the 32-bit WebRenderer libraries will be used.

The values for “arch” property are the same as is returned in Java by the function:

System.getProperty("os.arch")

As with all Applets, each library will need to be signed. Details on signing your Applets resources can be found here..

This demonstration application not only aids in browser navigation, but also shows how to draw on top of the WebRenderer browser. To enact a mouse gesture one holds down the right mouse button and moves the mouse in a direction or pattern and the browser matches this pattern against a predefined list. After the browser interprets the mouse movement pattern it is matched to a browser action, such as “go back” or “reload page”. Mouse gestures can be visually interpreted by the user thanks to a “tail” which is drawn on the browser (web page) as the user performs the gesture.

The mouse gestures example including source code can be downloaded here..

Below is a screen capture of a mouse gesture in action. The thick red line is the gesture being performed by the user. The gesture underway in this screen capture is telling the WebRenderer browser to “Go Back”.

The example code can be launched with RunGestureBrowser.bat (included in the download). This particular launcher is for Windows, using WebRenderer libraries, although the demo will work on any platform supported by WebRenderer.

SOURCE CODE
There are two Java files for this demo:

TestBrowser.java is the standard WebRenderer Test Browser with two extra lines of code calling the Gestures class.
Gestures.java contains the relevant code for implementing the mouse gesture trails and actions.

The mouse gestures example including source code can be downloaded here..

With that being said, for some time now our WebRenderer developer team has been utilizing a “Test Browser” that is rather substantial (130 classes) when compared to our standard Test Browser (one class). This test browser has been dubbed “Rich Test Browser” by the developer team. Given the amount of WebRenderer features demonstrated by the Rich Test Browser we thought it appropriate to publish the browser for all to use. The Rich Test Browser can be downloaded and includes both binary and source code.

Some of the WebRenderer Rich Test Browser functionality includes:

File menu:
Save As, Save to BufferedImage
Print Preview, Print Preview in New Window, Print

View menu:
Page zoom functionality, text sizing, text selection
Find functions including Find and highlight, Find next, Find previous

Go menu:
Navigation functions such as “reload” and “stop”
Load HTML from clipboard
Browser History functions

Extra menu:
Popup window handlers, scrollbar and scroll position manipulation
HTML Editing mode and insert HTML into page
Javascript execution, sending key presses
Custom protocols, image and plugin handling

DOM menu:
Functions to call many methods in W3C Document, Element and Range

Feel free to download a copy of the Rich Test Browser (including source code).

WebRenderer Swing Edition renders in lightweight Swing and is the only commercial strength Java™ browser SDK with this capability. New features found in the WebRenderer 6.0 include an updated Firefox™ engine, HTML5, SVG, Canvas, MathML and vastly improved font rendering. WebRenderer Swing Edition 6.0 also features much improved overall performance in the areas of JavaScript and rendering speed. The standard full-featured WebRenderer API is implemented and the W3C DOM and plugins such as Flash and PDFs are supported.

One major enhancement built into WebRenderer Swing Edition 6.0 is support for older operating systems and Java versions. WebRenderer will not only run on the newest Linux and OS X systems but also on older Linux systems and right back to Mac OS X 10.4. Java backwards compatibility is just as impressive with WebRenderer supporting right back to 1.4.2! This added backwards compatibility is achieved by removing front-end dependencies such as GTK on Linux and Solaris systems. This means that WebRenderer will run unmodified on older Linux platforms. Non-Linux platforms also benefit from the removal of external dependencies as evidenced by platform support right back to Mac OS X 10.4.

The release of the WebRenderer Swing Edition 6.0 demonstrates JadeLiquid’s ongoing commitment to provide the best solution for displaying web content within Java applications. Since the first release of WebRenderer in early 2003, WebRenderer has continued to break new ground in the Java browser SDK market. With millions of deployments world wide WebRenderer provides commercially robust web content display in Java applications. WebRenderer has the widest platform support of any commercial Java browser SDK including Windows, OS X, Linux, Solaris and AIX.

Features summarized:

– Lightweight Swing component
– HTML 5, JavaScript, SVG, Canvas, CSS, Ajax and plugin support
– 64-bit and 32-bit support on Windows, OS X and Linux
– API supporting complete Event model (network, mouse, key, browser, prompts)
– W3C DOM support
– Plugin support including Flash and PDF plugins
– Print and Print Preview support
– Embeddable in just 3 lines of code
– Completely standalone and self-contained – no external dependencies!
– Supports Java 1.4.2 to the latest (7.0)
– Deployment through standard JAR files including WebStart

To download a Free 30 day trial please visit www.webrenderer.com

Java Web Start provides for an efficient deployment mechanism for Java applications. Web Start is particularly suited to deploying applications that have multiple platform optimized libraries. WebRenderer is one of these such libraries. WebRenderer Swing Edition 6.0 is deployed targeting a single platform with 3 JAR files. The 3 core JARs are the webrenderer-swing.jar, webrenderer-swing-xxx.jar and the corecomponents-swing-xxx.jar. Note the “xxx” denotes the platform and the processor architecture. What makes Web Start powerful is that one can target the necessary libraries to the individual platform. This means that instead of deploying all the WebRenderer platform libraries (some of which would not be needed) one can target the resources to the platform, saving bandwidth and making the deployment process seamless.

The Java Web Start Resource tag

The “Resource” tag in the Java Web Start descriptor has two key elements to allow efficient Java application deployment. One important attribute of the resource tag is the “os” attribute. This attribute allows you to specify specific platforms for the deployment of your application. Options in the “os” attribute can be “Windows”, “Linux”, “Mac OS X” etc.

The next relevant resource attribute is the “arch” attribute. This attribute allows for the specification of the processor architecture. Relevant values for the “arch” attribute include “x86” and “amd64” (even for Intel 64bit). Additional “arch” values are seen below in the Web Start JNLP example code.

The following is an example of a Web Start JNLP file (“TestBrowserAllPlatforms.jnlp”):

<jnlp
spec="1.0+"
codebase="{Set the base URL here where all jars stored. For example http://www.webrenderer.com/webstart/}"
href="TestBrowserAllPlatforms.jnlp">

<security>
<all-permissions/>
</security>
<resources>
<j2se version="1.4+"/>
<jar href="TestBrowser.jar"/>
<jar href="webrenderer-swing.jar"/>
</resources>

<resources os="Windows" arch="amd64">
<jar href="webrenderer-swing-windows64.jar"/>
<jar href="corecomponents-swing-windows64.jar"/>
</resources>

<resources os="Windows" arch="x86">
<jar href="webrenderer-swing-windows32.jar"/>
<jar href="corecomponents-swing-windows32.jar"/>
</resources>

<resources os="Linux" arch="amd64">
<jar href="webrenderer-swing-linux64.jar"/>
<jar href="corecomponents-swing-linux64.jar"/>
</resources>

<resources os="Linux" arch="i386 x86">
<jar href="webrenderer-swing-linux32.jar"/>
<jar href="corecomponents-swing-linux32.jar"/>
</resources>

<resources os="Mac\ OS\ X" arch="x86_64">
<jar href="webrenderer-swing-osx64.jar"/>
<jar href="corecomponents-swing-osx64.jar"/>
</resources>

<resources os="Mac\ OS\ X" arch="i386 x86">
<jar href="webrenderer-swing-osx32.jar"/>
<jar href="corecomponents-swing-osx32.jar"/>
</resources>

<application-desc main-class="TestBrowser"/>
</jnlp>

Our complete documentation for Web Start deployment which covers start-to-finish preparation and deployment can be found here..

Steps to deploy WebRenderer Server Edition in Tomcat

1) Place all the WebRenderer libraries (webrendererse.jar, webrendererse-xxx.jar, corecomponents-xxx.jar) in your CATALINA_HOME/lib directory. Whatever you do, avoid deploying any WebRenderer libraries to your WEB-INF/lib or WEB-INF/classes directory.

The next two steps are Optional

2) You can control where WebRenderer extracts its components to using the BrowserFactory.setXXX methods. This is particularly helpful if you want to control the extraction and data storage of WebRenderer. If you do not set these methods WebRenderer will extract out to <USER_HOME>/.webrendererse directory. The following methods allow you to specify the home directories and library locations for WebRenderer:

BrowserFactory.setHomeDirectory(path_to_webrenderer)
BrowserFactory.setLibraryPath(path_to_webrenderer)
BrowserFactory.setMozillaPath(path_to_webrenderer)

3) Make note that when you are finished with the browser that you destroy it by calling browser.destroy(). This ensures that you do not have any memory issues caused by browsers hanging around when not in use.

That is really all there is to it. It is fairly straight forward and hassle free.