nifty-gui

Nifty GUI uses XML to store the layout of your GUI. To connect such a XML description with some class in Java there is the ScreenController Interface you need to provide:

/**
 * ScreenController Interface all screen controllers should support.
 * @author void
 */
public interface ScreenController {
  /**
   * Bind this ScreenController to a screen. This happens
   * when the Screen got the onStartScreen() method.
   * @param nifty nifty
   * @param screen screen
   */
  void bind(Nifty nifty, Screen screen);
 
  /**
   * called when all start effects are ended and the screen
   * is ready for interactive manipulation.
   */
  void onStartScreen();
 
  /**
   * called when the onEndScreen effects ended and this screen is done.
   */
  void onEndScreen();
}

To let Nifty know what ScreenController class you want to use for a Nifty Screen there is the “controller” attribute on the xml tag:

...
<nifty>
  <screen id="start" controller="com.mypackage.HelloWorldStartScreen">
  ...
  </screen>
</nifty>

To resolve the concrete ScreenController instance Nifty can use two different ways:

1. Nifty creates a new instance of the given ScreenController class and registers this instance with the Screen
2. You can give Nifty a ScreenController instance that matches the class given in the controller attribute. Nifty will first look for an existing instance and creates a new class only when it can’t find one.

To register ScreenController instances with Nifty there are additional parameters on the “fromXml()” method of the Nifty class. This way you can even add multiple different instances for use in multiple Nifty screens.

  /**
   * load xml.
   * @param filename file to load
   * @param controllers controllers to use
   */
  public void fromXml(final String filename, final ScreenController ... controllers) {
...

Note: You still need the controller attribute in the xml so that Nifty can connect the screen with your ScreenController instance.

Note: In case you use anonymous inner classes like in this example here:

class MyStuff {
...
nifty.fromXml("menu.xml", new ScreenController() {
    public void bind(Nifty nifty, Screen screen) {
...

the classname then turns to “MyStuff$1″.

In a previous blog post I’ve talked about that composition/delegation has some benefits over inheritance. Today I realized that I actually was right

As I was playing around in Nifty I’ve noticed that my TextElements don’t support coloured backgrounds. As a matter of fact the TextRenderer just didn’t support it. The first thought was to simply add this feature. But then I realized that the missing functionality was right there in front of me. I already implemented backgroundColor (and even backgroundImage) for Panels in the PanelRenderer.

So it occurred to me that I only have to combine them both in some nifty composition and be done.

So I’ve just changed the Element class to support not only a single ElementRenderer but several! And by the way I discovered the “varargs declaration” in Java:

public Element(
    final String newId,
    final Element newParent,
    final ElementRenderer ... newElementRenderer) {
  ...
}

You can use it this way:

Element element = new Element("myId", parent, new PanelRenderer(), new TextRenderer());

Nifty indeed

The feature to play soundeffects and probably music in Nifty was in the back of my head from the very beginning. And today I’ve added it and it worked like a breeze

Well, at first I went for something like adding it parallel to visual effects. Something like that:

<element>
  ...
  <effect>
    <onstartscreen name="fade"></onstartscreen>
  </effect>
  <onclicksound name="bleep"></onclicksound>
</element>

But then it occurred to me, that a sound *effect* is only a special kind of an effect! So I’ve quickly added a new kind of an effect: “PlaySound” and voila:

<element>
  ...
  <effect>
    <onstartscreen name="fade"></onstartscreen>
    <onclick name="playSound" sound="bleep"></onclick>
  </effect>
</element>

Feels good. Looks good. Is good. Was very quick to implement too!

Sometimes life is good!

Check the following code fragment:

    // get post mode and default to post = true, when nothing is given
    boolean post = true;
    if (effectType.isSetPost()) {
      if (PostType.FALSE == effectType.getPost()) {
        post = false;
      } else if (PostType.TRUE == effectType.getPost()) {
        post = true;
      }
    }

Although there’s no code duplicated in there (the root of all software evil), there is still some information duplicated. The comment repeats the same information as the code! And duplicate information is not good. If I want to change the default value I need to change two lines: the actual code and the comment. And maybe I forget to change one part and voila introduced inconsistence. Which comes back to me someday and is going to bite me.

So what to do, to make it still readable and easily changeable?

(more…)

I am refactoring Nifty-GUI’s internal workings. Trying to make it less inheritance dependent.

To manage all the Elements (Panels, Images, Text and so on) I have quickly and with not much thought introduced a Element class hierarchy as shown in figure 1.

figure 1: reasonable (?) class hierachie

Well, each Element has an “void abstract render()” method to render itself. This method is overwritten in the subclasses. This is reasonable because the steps you’ll need to render an Image are probably different to f.i. a TextElement. You have seen this kind of solution a million times before. So why should this be a bad thing?

(more…)