I’ve been doing some development using Griffon lately. Griffon is a Grails like application framework for developing desktop applications in Groovy which lets you create Java Webstart applications without the hassle. It takes a clean MVC approach including nifty automatic binding of the model to the view. If you want to give Griffon a go, please have a look at the Quick Start guide.
I was looking for a solution to run the application I wrote in fullscreen mode. It took me a while to figure out how to do this. In the end it was quite simple.
Griffon offers a couple of hooks to execute code on specific states of the application lifecycle. The following hooks are availlable:
- griffon-app/lifecycle/Initialize.groovy
- griffon-app/lifecycle/Ready.groovy
- griffon-app/lifecycle/Shutdown.groovy
- griffon-app/lifecycle/Startup.groovy
- griffon-app/lifecycle/Stop.groovy
I added the following code to the ‘griffon-app/lifecycle/Ready.groovy’ script:
[groovy]
import java.awt.GraphicsEnvironment
def graphicsEnvironment = GraphicsEnvironment.localGraphicsEnvironment
def device = graphicsEnvironment.screenDevices.find{it.fullScreenSupported}
device?.setFullScreenWindow(app.appFrames[0])
[/groovy]
The ‘app’ variable in the script is an implicit variable pointing to the actual application. Via this variable one can get access to all parts of the application; since I’ve just got one frame choosing was easy.
Haven’t had the change to test the above on windows… but it works like a charm in OSX.
Lucky you… getting a Swing application to run full screen used to be quite difficult (see http://java.sun.com/docs/books/tutorial/extra/fullscreen/index.html).
@levi_h
well that tutorial is exactly what I used to understand how the Swing part of the story works; is this an old-fashioned approach?
That’s hard to say for The Java Tutorial – some of the parts really show their age. But if it’s not, I wonder whether calling #setFullScreenWindow only will be enough. I mean, why all the code (in the tutorial) when all you need is a single statement?
well, you’ll need to get hold of a device the call #setFullScreenWindow on. If you refactor all the boilerplate Java code to Groovy the above is what remains.
Yes, I understand that… I was actually thinking about active vs passive rendering and examples like http://java.sun.com/docs/books/tutorial/extra/fullscreen/example-1dot4/MultiBufferTest.java, which contain a whole lot more than a single setFullScreenWindow call. After reading a bit more, I see
Feel free to use passive rendering if you just want a simple full-screen Swing or AWT application, but remember that paint events may be somewhat unreliable or unnecessary while in full-screen exclusive mode.
which I remembered apparently.