So there is now a 1.3.1 branch in git. But wait! Doesn’t Nifty consist of lots of individual jars (nifty, controls, style, renderers, sound-system implementations and so on)? So we need a branch for each individual jar, don’t we?

Yes, but fortunately we can combine all of the individual maven projects into a multi-module maven project. This way we can now build the nifty-core project together with all of the dependent jars. This gives us the additional benefit to use the parent pom to define versions for plugins we use as well as common dependencies in one place instead of all the individual poms.

To combine the different repositories into one we’ve used yet another feature of git. It’s possible to treat another git repository as a remote repo when both exist on the same filesystem. And this his how it works:

git remote add <name-we-want-to-give-this> /path/to/other/repo/.git
git fetch <name-we-want-to-give-this>

And that’s all! We can now merge with this remote one exactly the same as with any regular branch!

So with all of the projects merged into one repository and with all of the maven multi-module setup in place everything looks pretty again. Instead of the individual projects/repos we only need to branch a single git repository/maven project. Here is the Nifty 1.3.1 Branch in the Git Repository.

The current development is concentrating on Nifty 1.3.1. This version will contain bugfixes and improvements based on the Nifty 1.3 release. 1.3.1 will be compatible with 1.3 and will especially improve Niftys performance. For instance with some of the latest commits Nifty will now generate much less new objects each frame which will reduces the amout of GC runs necessary by quite a bit already

There are some other performance improvements scheduled as well especially to improve the rendering speed of text elements.

void

Example

You can check the first example of the new ListBox online with the following Webstart URL:

The source code of this project is available online. You can check out the source directly from SVN using https://nifty-gui.svn.sourceforge.net/svnroot/nifty-gui/nifty-default-controls-examples/trunk or you can browse it online here: http://nifty-gui.svn.sourceforge.net/viewvc/nifty-gui/nifty-default-controls-examples/trunk/.

And if that is not enough … we’ve done the same new API treatment to the CheckBox and we plan to do the same to the remaining Nifty Standard Controls!

Reference in the Wiki

You can find a complete reference about the new standard controls in Nifty 1.3 already on the Wiki (for the ListBox and the CheckBox):

http://sourceforge.net/apps/mediawiki/nifty-gui/index.php?title=Nifty_Standard_Controls_%28Nifty_1.3%29

And you can keep reading about all the little Nifty details we’ve changed and improved and especially why.

It all started with a feature request for Nifty 1.3 which seems easy to add at first. Removing all or single elements from a Nifty ListBox sounds like a reasonable feature to have available. So I’d try to add this … and failed miserable! The closer I looked into it the more despaired I’ve become.

What a mess!

Something I’d really love to do with Nifty 2.0 is to add a nice and clean API to the standard Nifty controls. The current way of interacting with most of the Nifty controls is kinda awkward (at least) and I want to improve this. So, I thought, hey, why not try to define a new API for the ListBox as a preparation for this and see how everything works out. Well, it turns out that in the end I’ve pretty much rewrote the whole ListBox! =) And that the new one is way better than what you currently have available!

One of the shortcomings of the old ListBox was speed. Internally it directly added the Nifty element tree adding elements dynamically and then used a Scrollpanel to scroll around that (maybe) huge list of elements. So basically it always rendered all elements and used the clipping of the element to hide everything that was not currently seen. Not a great idea after all

Another problem was the API and that’s a little difficult to interact with Niftys internal screen representation. Although it’s not impossible to dynamically add/remove elements from Nifty this might not be the ideal solution to the ListBox problem.

So what did we changed? Well, actually a lot!

The new ListBox:

• Instead of relying upon the scroll panel we now only use Nifty elements for what you can see and simply replace the content of the elements when you scroll to a big list of items. So, when your ListBox only display 4 elements there really are only 4 Nifty elements allocated. Of course the ListBox allows many more Items to be added but in that case only the content of the 4 elements are replaced. You can now specify how many elements you want your display to show with the “displayItems” attribute.

• Scrollbars are now optional and you can disable them completly with the “vertical” and “horizontal” attributes. Simply adding for instance vertical=”false” to the ListBox will hide the vertical Scrollbar.

• The ListBox now supports single as well as multiple selections. This means you can now configure your ListBox to allow the selection of only a single item or that you want to select multipe items. If you don’t want to allow selection at all you can even disable the selection completly.

• Instead of relying on storing Strings the new ListBox allows you to story your own Objects directly. So say you want your user to select different space ships by the name of the ship you could simply store your “Ship” instances directly in the ListBox. Nifty determines what text it should display for your instance by calling toString() of your objects. If this is not suitable for you, you can change this by setting a specifc ListBoxViewConverter for your class.

• The new ListBox now features a pretty complete API ListBox that allows you to dynamically add, remove, select, clear items to the ListBox. This is now all available using generics..

EventBus Notification

In the process of updating the ListBox we’ve noticed that we’re missing a nice way to allow the controls to notify other components of the system about things happening. If the selection of the ListBox is changed we’d like other parts to be notified about that event. Well, the first thing that comes to ones mind is of course the Listener/Observer pattern. But there are some problems with this approach, mostly the strong binding between the objects that communicate. There is a great PDF available from the OSGI people that discusses some of the problems of the Listener pattern.

Having previously worked with GWT 2.x and its event bus architecture we’d like to have someting similar for Nifty too. What we want is a loose coupling between Nifty (as the creator of events) and your application (as the receiver of the events). As it turns out a publish/subscribe mechanism allows us to do just that! Nifty publishes events to some “global” EventBus. And your application on the other hand subscribes to this EventBus for all the events that it needs to handle. What sounds not very different from the standard Listener pattern at first is in fact a great improvement! There is only a dependency to the EventBus and not between the objects that communicate! Which helps a lot to decouple the objects from one another. Nifty does not need to know who will receive the event in the end. It just creates the event and publishes it to the EventBus and everybody interessted in it will be notified.

As it turns out there is a neat little project available that implements that mechanism for us. It is called EventBus and is available as Open Source under the Apache License, Version 2.0. It’s only 80KB in size, so it should not hurt the download/memory footprint of Nifty that much. Nifty is now using the EventBus project for ListBox and CheckBox notifications which worked very very well so far! You subscribe to the EventBus using the id of the element as a topic and you’ll receive all events that the control with the given id produces. In the case of the ListBox this means that you receive instances of the ListBoxSelectionChangedEvent. This basically sends you the current selection of the ListBox everytime the selection has been changed

Good Times,
void

PS: And if you NOW don’t feel like christmas is already here then I can’t help you =)

In order to improve the usability of Nifty, Nifty user arielsan of gemserk has started creating a “Builder Pattern” based way to create Nifty GUIs. These classes can be used from within java to create a Nifty GUI without the need for an external xml file.

We have improved the solution together and there is a Nifty ScreenBuilder class available as your starting point. Here is a quick example what you can do with it:

Screen mainScreen = new ScreenBuilder("main") {{
  controller(new ScreenControllerExample());

  layer(new LayerBuilder("layer") {{
    backgroundColor("#003f");
    childLayoutCenter();

    panel(new PanelBuilder() {{
      id("panel");
      childLayoutCenter();
      height(percentage(25));
      width(percentage(80));
    }});
  }});
}}.build(nifty);

Nifty gives you an easy to use framework that you can extend with your own ideas. Just like Nifty user zozo64 did. Nifty is missing drag and drop support? No problem! He created his own!

To be honest, he found some bugs too but all of that improved Niftys core systems. So that’s a good thing. We’ll probably bring his work as a standard drag and drop control into the standard controls project soon.

For the moment you can take a look at the code. It’s part of the nifty examples project:

http://nifty-gui.svn.sourceforge.net/viewvc/nifty-gui/nifty-examples/trunk/src/main/java/de/lessvoid/nifty/examples/dragndrop/

And here is a first preview of zozo64 work:

Nifty Basic Drag and Drop from void on Vimeo.

You can follow both threads at the Nifty Help Forum at sf.net:

Changing Button Text Thread

Resizing Buttons to Text Thread.

Read the complete blog post for details.

Dynamically changing text was easy and has been added to the ButtonControl. You can now simply change text with the following code from java:

screen.findControl("backButton", ButtonControl.class).setText("New Text");

Automatically resizing Buttons was a bit more involving tho.

Nifty actually has build in support for resizing elements according to other elements. But before we can understand what that means we first need to know a bit about the internal workings of a Nifty Button Control.

A Nifty Button consists of a Panel element with childLayout=”center” and one child element which is a Label element that represents the actual button text. So far so good and the standard style set (nifty-style-black) simply adds a fixed width to the button.

So simply using the Button control:

<control name="button" label="Hello World" />

will give you a button with a style specific fixed width.

You can override this fixed width when you use the button control like that:

<control name="button" width="4532px" label="Hello Large Button World" />

This works pretty good if you don’t need to change the button label text. No matter what you do to a button with a fixed width it will always stay at this width (Unless you change the width constraint from code as one of Jattras code examples shows. And although this works it is a bit cumbersome but until now the only way to achieve resizing buttons).

So what should we do to fix this?

Well, actually there is not really much to do. If you ever used a childLayout=”vertical” on something without setting a width but every child in that special element had a fixed size you already have seen that Nifty actually resizes the parent element!

And this is basically default behaviour in Nifty: Whenever Nifty finds an element without a width (or height) constraint it looks at all the child elements and if they all have a fixed width (or height) it automatically resizes the parent element to the size of all child elements.

And this is just what we need here

As stated above the Button control uses childLayout=”center” and up until now the center layout did not support this kind of auto-resizing feature. But this has been added to svn a moment ago.

So whenever Nifty encounters an element with childLayout=”center” and the child element has a fixed width then it will resize the element to the child width. And this works for our button control too! And it works even when dynamically changing text from within Java

Well, there is one thing to note tho. For backward compatibility the nifty-style-black still sets a fixed width to the button. So to enable the auto resizing you have to override the witdh of the button with an empty String.

Example to enable the auto resizing Button:

<control name="button" width="" label="autoresizing button"/>

And that’s it.

Note:
Another thing to note is, that the change to the center layout logic now requires you to set a width to all elements that use childLayout=”center”. Before this change there was no auto resizing done to elements that use center layout. To prevent the auto resizing that will be used on that elements now you need to specify a width to this elements.

In the process I just want a moving Nifty GUI Logo like this one

So the logo should resize while fading in and keep on resizing while fading out.

My first try was this xml (only the resizing part is shown with the “imageSize” effect attached to “onStartScreen”):

<onStartScreen name="imageSize" startSize="0.7" endSize="1.0" time="600" neverStopRendering="true" />
<onStartScreen name="imageSize" startSize="1.0" endSize="1.3" time="600" neverStopRendering="true" startDelay="600" />

Which was reasonable but doesn’t work. It doesn’t work because effects with a startDelay are in fact already active. In this case the second onStartScreen imageSize effect overwrites the first one with it’s intial startSize of 1.0 for the time the startDelay is active. Which, yeah, makes sense for most effects but sucks in this case.

What I’d really want to write is this instead:

<onStartScreen name="imageSize" neverStopRendering="true">
  <value time="0" value="0.7" />
  <value time="600" value="1.0" />
  <value time="1200" value="1.3" />
</onStartScreen>

Well, and now you can actually write it like this!

What this does is performing linear interpolation for of the given values. In the example above the value for the imageSize effect starts with 0.7 and changes to 1.0 over a time of 600ms. After that it continues to be interpolated from 1.0 to 1.3 for the next 600ms. When value tags are present they will overwrite the length parameter of the effect. So in the example the imageSize effect will last for 1200ms.

I’ve just commited this to svn. It is still work in progress and is therefore only available for the “imageSize” and the “fade” effect. I’m currently thinking about extending it to other effects where it is appropriate. I’m also considering to not only interpolate float values but to make it more general and the actual values are effect specific, so that you could interpolate color values for instance.

void

When using Nifty together with Slick2d this is represented by the NiftyGameState class. Using this class your Slick2d StateBasedGame can easliy switch from your in game state to the NiftyGameState and display the GUI.

But this is not the only way Nifty can be used. You can easily use Nifty to render your in-game GUI too! Nifty plays well with others (as long as they use OpenGL/lwjgl for rendering that is).

It’s not complicated at all and I wanted to write example code that demonstrates how easy it is for a long time. Motivated by a question at the Nifty Forum at souceforge.net I did now

What’s demonstrated in the new slick example is, how you can use Nifty to render a GUI on top of a normal slick GameState.

Here is a screenshot of the example which renderes Text from within Slick that changes color when you press the keys 1-3. On top of this it renders a Nifty GUI that responds to mouse events. Additionally if you press 1-3 the colored Nifty boxes start to shake

Slick Overlay with Nifty GUI

You can try it out with the Webstart:

http://nifty-gui.sourceforge.net/webstart/nifty-slick-overlay-demo.jnlp

and you can find the example in svn or you can browse it online here:

http://nifty-gui.svn.sourceforge.net/viewvc/nifty-gui/nifty-examples/trunk/src/main/java/de/lessvoid/nifty/examples/slick/niftyoverlay/ (Java classes)

http://nifty-gui.svn.sourceforge.net/viewvc/nifty-gui/nifty-examples/trunk/src/main/resources/slick/niftyoverlay/overlay.xml?revision=534&view=markup (Nifty XML for the Screen – overlay.xml)

Keep reading the full Article to see the details on how we get this to work and what you need to consider.

The way it works is pretty easy and it even works with anything you’ve rendered in lwjgl. Slick is not required but as shown it works very well with Slick too.

So you just need to:

1. Save your current OpenGL-State and enable 2d Mode
   You have to make sure you save your current OpenGL state and make sure you are in 2d “mode” before calling Nifty. Which means that everything is setup for 2d OpenGL rendering (orthogonal projection, modelview matrix aligned with the screen, etc. In Slick this is all handled by a single call to SlickCallable.enterSafeBlock(). This makes sure that the current Slick state is saved and changes in Slick or Nifty don’t disturb each other (we’re already in 2d mode too because of slick).
2. Call Nifty to render its GUI
   You call Nifty.render() to render the Nifty GUI. You can call render() with a boolean parameter that tells Nifty to clear the screen (parameter = true) or if it should not clear the screen at all (parameter = false). If you are rendering an overlay you probably want to leave the screen as is and render your GUI on top. So in this case simply call nifty.render(false).
3. Restore your State and continue your own Rendering
   When nifty.render() returns you can reset your state so that you can continue rendering 3d triangles or whatever you want to render on top (!) of Nifty GUI. Again in Slick this is a single SlickCallable.leaveSafeBlock() call.
4. Forward KeyEvents
   You decide if keyEvents get past through to Nifty by calling nifty.keyEvent() with the events you want that Nifty gets. If you don’t call keyEvent() no key events will get to Nifty what might or might not be what you want.
5. Forward MouseEvents
   Handling mouse events are a bit trickier because they are handled through the InputSystem interface which you need to call the Nifty constructor with. But creating an implementation of the InputSystem is easy because at the moment it only consists of one method that Nifty uses to request a List of current available MouseEvents. So you’re implementation can decide when and what mouse events get through to Nifty in the InputSystem-Implementation.

The example in nifty-examples svn demonstrates how to forward MouseEvents but does not care about keyboard Events.

And that’s it! Nifty GUI playing together with others! Nifty!

void

So now we’ve extracted the resources into a separate “nifty-default-styles.jar”. The “nifty.jar” now only contains the actual code and is only 280 KB big

Now you’ll need both jars in your classpath when you want to use the default styles but you can add your own of course.

Currently only available in svn or in the latest 0.0.5-snapshot.

Nifty

/**
 * 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″.

Nifty XML with Style – a lot better

Nifty XML Style Definition

<!-- main menu style -->
<!--
  <attributes childLayout="vertical" align="center" valign="center" height="50%" />

  <effect>
    <onStartScreen name="hide" length="500" inherit="true" startDelay="1000" />
    <onStartScreen name="fade" startColor="#fff0" endColor="#ffff" length="1000" startDelay="500" inherit="true" />
    <onEndScreen name="fade" startColor="#ffff" endColor="#fff0" length="500" inherit="true" />
  </effect>
-->
 
<!-- menu item style -->
<!--
  <attributes align="center" />

  <hover width="200%" falloffConstraint="horizontal" />
  <effect>
    <onFocus name="pulsate" hoverWidth="200%" width="200%" period="500" startColor="#3c000000" endColor="#ff7c00ff" timeType="infinite" cycle="false" />
  </effect>
-->