
If you look at the original code you will notice there are four components with custom painting and a Main class that serves as application builder and entry point. The first iteration of this experiment will concentrate on porting the app 'as is', with no major tweaks to the painting code, here are a couple of screenshots of the finished app


Ok, I couldn't resist adding a minor tweak in terms of the app's behavior. Notice that when the Black theme is the current one, the "Red Theme" button is the only one enabled, the inverse is also true when the Red theme is enabled. This is probably related to binding as we will see next. So the first thing with any Griffon app is create the application's layout, once you have Griffon installed on your system type
griffon create-app FuseDemo
Next step would be adding the required libraries (fuse-core, fuse-swing) to the application's lib directory (you can get them from Fuse's project site), also all sources and resources from the original demo except the MainFrame class. Sources should be place under src/swing, resources should be placed under griffon-app/resources/swing. We are ready to write the view
Alright, so we have two actions that trigger the theme change, whose enabled property is bound to the current themeId value (handled by the model). The layout mirrors the one found in MainFrame. Now let's look at the controller code, which is the one that handles the theme change using a SwingHive
Changing a theme requires a naming convention (at least for this particular example, not just because of Fuse or Griffon themselves) so that the exact location of a ui theme is not exposed. Remember that the value of themeId is set on the actions, using handy constants available on the model class, which is the next source
Is that all? pretty much, but there is a missing piece of the puzzle, we have to instruct the SwingHive to inject the resources into our components, that is why the controller has a injectResources method. But where should we make the call to inject those resources? thankfully Griffon defines a set of lifecycle scripts that are called in an specific order: Intialize, Startup, Ready, Stop and Shutdown; the one we need is Startup (found in griffon-app/lifecycle/Startup.groovy) as it is called after the view has been built but before the app has finished bootstraping itself, it is just a matter of adding 3 lines of code
Don't forget that if you want a nice looking app (with native L&F where available) and MacOSX friendly menubars you should add the following to griffon-app/lifecycle/Initialize.groovy
And that is the whole code, you should have a working example of Fuse enabled Griffon application, you can run it by issuing the command
griffon run-app
You may probable be wondering if we could do better, sure! what about automatically registering the components that require Fuse injected resources? or tweaking the custom paint code with a groovier way (hint: GraphicsBuilder)? those questions will be answered in future posts, stay tuned!

Keep on Groovying!