[SOLVED] NiftyGUI OnClick Effect is not working on keyboard events



If pressing enter or space keys when having focus on a nifty element with an interact tag the onclick event is not run although according to the manual it should: “OnClick: The element has been clicked by the mouse or is activated by a keyboard interaction”.

The interaction method defined is properly called in any case (clicking or pressing keys).

Maybe I’m doing something wrong but just in case I’ve prepared a simple testcase:

Nifty xml file:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<nifty xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://nifty-gui.lessvoid.com/nifty-gui" xsi:schemaLocation="https://raw.githubusercontent.com/void256/nifty-gui/1.4/nifty-core/src/main/resources/nifty.xsd https://raw.githubusercontent.com/void256/nifty-gui/1.4/nifty-core/src/main/resources/nifty.xsd">

  <useStyles filename="nifty-default-styles.xml" />
  <useControls filename="nifty-default-controls.xml" />

  <registerSound id="menuSelect" filename="Button.ogg" />
  <style id="menu-item">
    <attributes align="center" valign="center" textHAlign="center" color="#fd0f" width="100%" font="barbatrick-30-3-8-0.fnt" 
                focusable="true" visibleToMouse="true"
    <interact onClick="" />
      <onHover name="focus" />
      <onFocus name="textColor" color="#ff0f" />
      <onFocus name="textSize" startSize="1.0" endSize="1.25" length="150" />
      <onLostFocus name="textSize" startSize="1.25" endSize="1.0" length="150" />
      <onLostFocus name="textColor" color="#fd0f" />
      <onClick name="playSound" sound="menuSelect" />
    <screen id="GScreen0" controller="mygame.Main">
        <layer id="GLayer0" childLayout="absolute">
            <panel height="100%" width="100%" childLayout="vertical">
              <text id="item" text="test" style="menu-item" >
                <interact onClick="test()" />
                  <onClick name="playSound" sound="menuSelect" />

Java code:

package mygame;

import com.jme3.app.SimpleApplication;
import com.jme3.material.Material;
import com.jme3.math.ColorRGBA;
import com.jme3.niftygui.NiftyJmeDisplay;
import com.jme3.renderer.RenderManager;
import com.jme3.scene.Geometry;
import com.jme3.scene.shape.Box;
import de.lessvoid.nifty.Nifty;
import de.lessvoid.nifty.screen.Screen;
import de.lessvoid.nifty.screen.ScreenController;

 * This is the Main Class of your Game. You should only do initialization here.
 * Move your Logic into AppStates or Controls
 * @author normenhansen
public class Main extends SimpleApplication implements ScreenController {
    private Nifty nifty;
    NiftyJmeDisplay niftyDisplay;

    public static void main(String[] args) {
        Main app = new Main();

    public void simpleInitApp() {
        niftyDisplay = NiftyJmeDisplay.newNiftyJmeDisplay(
        nifty = niftyDisplay.getNifty();
        nifty.fromXml("main.xml", "GScreen0", this);

    public void simpleUpdate(float tpf) {
        //TODO: add update code

    public void simpleRender(RenderManager rm) {
        //TODO: add render code
    public void bind(Nifty nifty, Screen screen)

    public void onStartScreen()


    public void onEndScreen()
    public void test()



If I had to guess without trying to run the code… you set the style as “menu-item” and that style sets the controller for that element as “de.lessvoid.nifty.controls.MenuItemControl”. So i’d be willing to bet that if you set breakpoints in the nifty code that it would be attempting to call “test()” on that control and not your “Main” class.


Thanks for the reply but the issue is not that the interact callback is not being run, which is run properly (if clicking or pressing enter or space the application outputs “Clicked!”). The problem here is that the onclick effect, playing a sound is only run when using the mouse but not when using the keyboard while according to the documentation and if I’m not wrong it should


Maybe a Nifty bug then. It would be awesome if you could debug and make them a PR. They still actively react to bug reports and PRs. But I’d hold my horse if expecting them to fix it quickly by themselves :slight_smile:


Following you advice I’ve been debugging it and I think I’ve found out why onclick effects were not run when receiving keyboard events and how to solve it. I Created a github issue and I’ll create also a PR so it gets updated in nifty and hopefully in the medium term in jme3


This is why I shouldn’t respond to threads without coffee in the morning :tired_face: I am surprised that controller mapping works, however, with how finicky it usually is.


Just in case anyone is interested in this issue, the PR was accepted, and later fixed because a missing import: https://github.com/nifty-gui/nifty-gui/pull/454 So I assume next jme release will include new nifty and the fix


Not unless they release a new version of nifty I would think.

That doesn’t seem to be in the cards either so…


We have coordinated a release with Nifty people before. It should be no big thing. I would just maybe like to see at least https://github.com/nifty-gui/nifty-gui/issues/461 fixed also before requesting a new version. I think this is from @glh3586 :slight_smile:


They actually did a 1.4.3 release. Sadly no fix for the https://github.com/nifty-gui/nifty-gui/issues/461. But the issue in this topic was included. Now we just need to set jMonkeyEngine 3.3 to use it. I didn’t try yet, but there are some breaking API changes. At least for those constructing the UI in code with the builders.


Wow, that is surprising. Sadly, I have to stick to my custom build of nifty until they fix that memory leak (I disable the style listeners since the feature isn’t used by stock nifty).


PRs they take in yes, but yours didn’t include one. And reading the discussion it is not that simple. By plugging the memory leak, they would cause more headache to you? By the added processing cost.


You are right it isn’t a simple fix. Personally, I would just remove the functionality completely since I don’t find it useful, but that potentially breaks functionality if someone depended on that feature which is why I didn’t include the pull request. It is basically the nuclear option to fix the problem. I’ll try to take another look at it when I look into some other batch rendering performance problems soon.