James Williams' Blog

 In case you haven't already heard from Twitter, Griffon will be represented in a BOF lead by Danno Ferrin and myself.

Next month, I'll be leading a presentation for the Sydney Groovy Group. The location hasn't been announced by the date and time is March 25th at roughly 7P local time(8AM UTC/1AM PST/4AM EST). The video will be up shortly after that you should try to attend (if you're in Sydney) or catch the live stream(on this blog) as I'll be answering questions after the presentation.

Though I wasn't able to release an app this weekend, nonetheless Weekend Apps - Opensocial was a great experience. For those that know nothing of the technology theme, Weekend Apps is an efficent way to get weeks of experience in a weekend having industry experts there to help you through problems.

One of the "a-ha" moments for me was learning that OpenSocial gadgets can run arbitrary html and thus can have embedded applets (as they already support embedded flash). For a user with Java 6 installed, the ability to drag the gadget outside the OpenSocial container and continue to run it after leaving the page might make for a killer app.

I was able to very quickly get a draggable gadget working using sample code from Sun. Code here

The only caveat is that because applets autostart, some care needs to be taken to handle things if the user minimizes a gadget then expands it. One might have the landing page be a static image of the app that the user would have to click to run it.

MozSwing is kinda has been in the back of my mind for a while now. We (the Griffon Team) even evaluated it for one of our early builds. But we thought, "JWebPane is going to be out soon and probably will be more lightweight than MozSwing(50MB)." Needless to say, JWebPane is no where to be found so I thought it would a good idea to reevaluate MozSwing.

Before you object and say your project can't accommodate an increase in size of 50MB, it won't be that much. Best case scenario, it would be 2MB, worse case is 24MB. The reason for the span in sizes is that MozSwing bundles xulrunner for all major platforms(Win32, Linux, OSX, and Solaris). If XULRunner is already on the machine, you only need 2MB of jars and it'll generally pick up whatever plugins you have installed for Firefox.

The demo app runs at this point but not in a Griffon context. It can't seem to find xulrunner without being told the path. I just set up an environment variable for it under XULRUNNER_HOME and overrode that line in MozillaConfig.

For those that are getting tense, you don't have to build MozSwing. Just open up the mozswing jar in your favorite archive manager, navigate down to the org/mozilla/browser and delete everything that
starts with MozillaConfig. Grab MozillaConfig.java, drop in the src dir of your Griffon app and add/modify this line

private static File xulRunnerHome = new File(System.getenv().get("XULRUNNER_HOME"));

Now you can call new MozillaPanel() to create a browser panel and load("address") to load an address in that panel. And here is the photographic proof that it works:

Because of Linux's modular nature, you have to explicitly copy plugins from your Firefox installation to the XULRunner directory whereas Windows seems to pick up those plugins automatically. Plugin sitch is unknown on OS X or Solaris.

Mozswing http://sourceforge.net/projects/mozswing

Update: It is noteworthy to mention that JDIC has had a JDICplus project for a while integrating IE in Swing but because IE is dying and is mostly non-compliant to standards, I don't see it as a viable option.

Update: While doing research for this post, I found this link dated Jan 29th from Tech Crunch, Adobe AIR Is Flying: 100 Million Installations Accounted For .

With the improvements from the last post, adding JOGL support to Griffon is now incredibly easy. Assuming you have a fairly recent revision from SVN, add the following closure to Config.groovy in the griffon closure:

extensions {
		jarUrls = ["http://download.java.net/media/applet-launcher/applet-launcher.jar", "http://download.java.net/media/jogl/builds/archive/jsr-231-webstart-current/jogl.jar"]
		jnlpUrls = ["http://download.java.net/media/jogl/builds/archive/jsr-231-webstart-current/jogl.jnlp"]
}

There is a little setup you'll need to do to initialize the canvas:

class JoglDemoController {
    // these will be injected by Griffon
    def model
    def view

    void mvcGroupInit(Map args) {
	model.canvas = new GLCanvas(createCaps())
	model.animator = new Animator(model.canvas)
	model.canvas.addGLEventListener(new Lesson03())

	model.animator = new Animator(model.canvas)
        model.animator.start()
    }
    
    def createCaps = {
	def glCaps = new GLCapabilities()
	glCaps.with {
	   setRedBits(8)
	   setBlueBits(8)
	   setGreenBits(8)
	   setAlphaBits(8)
	}
	return glCaps
    }
}

Next, we add our canvas and helper variables to our model and view:

class JoglDemoModel {
   @Bindable canvas
   @Bindable animator
   @Bindable gl
}

JoglDemoView.groovy

application(title:'jogldemo',  size:[512,384]) {
    widget(model.canvas)
}

On our canvas, we use a slightly tweaked Java file from the Nehe examples.

Lastly, we need jogl.jar. This will enable run-applet and run-webstart. To get run-app working, you would have to install your specific operating systems native OpenGL libraries(.dll's on Win, .so's on Linux, .jnilib's on OSX). Download jogl.jar and/or OS-specific files.

I used Lesson03 from Nehe mostly unmodified.

Download the project.

One of the previously unimplemented features of Griffon was real support for remote JARs and JNLPs. Sure you could add them after the fact but it didn't really matter because calling run-webstart or run-applet would regenerated all the files anyway, destroying any changes you had made.

Griffon now has basic support for remote JARs and JNLPs. These are essential for avoiding the need to package libraries that have OS-specific implementations such as JOGL.

To add a remote JAR or JNLP, add the following closure under the griffon closure in Config.groovy:

extensions {
    jarUrls =  [ (jar urls here)]
    jnlpUrls = [ (jnlp urls here)]
} 

Griffon takes this info and builds the appropriate applet embed code(both new school and old school) and webstart files with jnlp extensions. This has not been pushed into a release yet so if you want to try it out, you'll need to build from SVN.