nifty-gui

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