nifty-gui

Removing XmlBeans and Commons-Logging reduced the nifty with all dependencies jar from 4,4 MB to 1,6 MB

Check it out here

Nifty Project Page at Sourceforge

or get the release here

Nifty Release Download

Have fun =)

Actually I like XmlBeans a lot. Define a XML-Schema (XSD) for your XML-File, throw XmlBeans at it and let it generate some Java classes. Voila. XML-Binding. Validate against the XML-Schema, easily access your XML-File from within Java, etc… XML? Java? Done!

There’s even a Maven Plugin for it, so one can generate the classes on the fly within your build process. Great Stuff!

So why would some half insane person want to removed it?

Well, one drawback is the size of the lib. Because XmlBeans is your Swiss army knife of XML-Java-Binding it is rather large being around 2,6 MB in size. Altough this is not that bad in DSL-century you can still notice it when running a Java Applet or Java Webstart.

Another and somewhat profoundly drawback is, that in a Java Webstart it seems to parse Xml-Files very very slow. I’m not sure what exactly causes this slowdown but from what I grasp this might be a classLoader issue or something. When run localy everything works fine but from within a Webstart Version it runs painfully slow. I’ve tried to pinpoint what causes these issues but had not much luck in doing so.

Now I’ve settled to get rid of XmlBeans and replace it with some simpler form of xml parsing. What I’m currently using is XPP3. Hopefully this will remove the issues. The lib is very small (25 KB) and very fast. The only drawback so far is that I lose the Schema-Validation. I’ll keep the XML-Schema for development and documentation purposes but the actual Loader inside Nifty won’t check against the Schema anymore. Which is a bit sad but something I can’t do anything about at this very moment.

Nifty sourceforge.net project available

Nifty Website available 

Have fun

void

I’m currently preparing the first alpha release of Nifty and moving the source over to sourceforge.net. This means you get access to the source as well as a first release of Nifty to play with.

There’s a new nifty-example.jar on the way too

Stay tuned … more news soon!

At the moment there are not many actual controls in Nifty. Besides from clicking on elements, f.i. an Image, there was so far not a lot of interaction possible.

Well, it’s about time to change this with Nifty Controls

To allow as much freedom as possible I’ve decided against predefining new control types that let you only change color or customize some images. Instead the idea is, that you use the already existing elements (Text, Image, Panel) and combine them to create the control you like.

You can create your own control with the <controlDefinition> Tag:

  <controldefinition name="coolControl" controller="my.package.SimpleSlider">
<panel layout="absolute" backgroundcolor="#f0ff">
      <img id="scrollposition" filename="ball.tga" />
    </panel>
  </controldefinition>

With this xml tag you can define a control like it is illustrated in figure 1.

A controldefinition actually defines a couple of things:

1. The name of the new control with the name attribute.
2. The control logic class with the controller attribute.
3. The actual look of the control with a combination of panel, image and text elements. You can even add effects. So if you want a hover effect you can simply add it to the control definition

With the mandatory attribute “name” you give your new control a name so that you can refer to it later. There’s another new tag to use your newly created control, the control tag:

  <control name="coolControl"></control>

So you define the look and feel as well as the control logic once and then use it everywhere you need it like figure 2 shows.

That’s all for now. This just covers the basic idea. More on controls later.

Have Fun!

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

Well, this took quite some time, but now it is finished and boah, I tell you IT ROCKS! An Introduction to Nifty written in Nifty!

It explains Layout, Effects and Interaction with Nifty and how it all links together. So don’t wait any longer and check out the Nifty introduction webstart.

And because you probably can’t wait any longer after you’ve seen all this, you can download the first alpha version of Nifty to try it all out by yourself! This is the “complete” Package with all dependent Jar-Files packages in a single Jar. So you don’t need any additional files (Note: A different Nifty-only Version will be available soon too). Required is a Java 1.5.

And in case you are curious how the introduction works you can take a look at the complete xml-file of the introduction.

nifty-0.2-complete.jar

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?

Read the rest of this entry »

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?

Read the rest of this entry »