nifty-gui

Getting DRY with style – the nifty kinda way :)

// May 24th, 2008 // No Comments » // design

Well, no, not “dry” … but “DRY – (D)on’t (R)epeat (Y)ourself” =)

Suppose for some reason you need a lot of red colored panels in your nifty screen. At the moment you’ll need to do something like this:

 ... 
 ... 
 ... 
...
 ...

So far so good, but what if you change your mind and want green panels instead? Ugly – no, not the color – but you’ll now have to change all this backgroundColor definitions. Quite ugly.

Introducing Nifty Styles
So what we really want, is to specify the color of the panels only one time and use it multiple times.
So with Nifty 0.0.3 you’ll be able to use style definitions to get DRY =)

<!--
  <attributes backgroundColor="#f00f">
</attributes>
-->
 ...

This way you can define common attributes once and use them multiple times! This principle will be extended to attributes, effects, fonts and so on. This is not only nifty but will naturally lead to UI-skins! Imagine you have all your style definitions in one big “style.xml”. So you could define colors, fonts, effects, etc. once in this file. Changing this single file or including another style.xml whould change your whole UI!

Nifty indeed

And still work in Progress too =)

Composition again…

// January 22nd, 2008 // No Comments » // design

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

Adding Sound – Easy!

// January 6th, 2008 // No Comments » // design

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!

DRY – Don’t Repeat Yourself

// December 30th, 2007 // No Comments » // design

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…)

Prefer composition/delegation over inheritance is a good thing!

// December 29th, 2007 // No Comments » // design

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…)