How do I deactivate a Nifty screen?

I know I could simply gotoScreen, but I don’t always know which screen to go to next.

I have tried getViewPort().removeProcessor(NiftyJmeDisplay), but that leaves the old screen displaying. I’m probably using the wrong API there… but I don’t know what the right API would be.

I would want to know this

How about nifty.exit(); ?

1 Like

Create a blank screen called “blank” then nifty.gotoScreen(“blank”) or do screen.getRootElement().setVisible(false);

gotoScreen(null) might work as well, I’ve never tried it, but I know the above two will work.

@zarch There’s also a NullScreen class, so no need to build a “blank” screen :slight_smile:



@madjack Nifty.exit seems to hit the nail on the head.

It ends the current screen (sounds good) and does something that looks equivalent to goTo(new NullScreen()).

I’ll try it out and tell how it worked.

Dammit. Nifty.exit() doesn’t work.

No crashes, no error message in the log, the screen just stays up. And the new screen doesn’t get installed either.

Probably some d’oh moment in my own framework code. I’ll let you know when I know for sure that’s going on.

@zarch gotoScreen(null) would work, just as gotoScreen(“any screen id that wasn’t registered”). However, that causes a warning in the log.



I was wrong with gotoScreen(new NullScreen()), gotoScreen wants a screen id (i.e. a String). I keep getting hit by that, it’s a very unusual (and, IMNSHO, broken) API design.

If nifty.exit() doesn’t work you might want to test using nifty.update() right after the exit call. But, considering, I think this might not work after it exited. Worth a try though.

Given that JmeNiftyScreenProcessor has a commented-out call to nifty.exit(), I don’t believe it will work.

It seems that JME is built for having just one Nifty object and you just cycle through the screens (with an occasional Null screen if you have no HUD).

That approach is valid, but you can get ID name conflicts that way. I’d have preferred some way to avoid that… ah well.

I’ve reread the posts and honestly I’m not sure what exactly you’re trying to do anymore.



I’ve got several nifty screens (XML-based) and I can switch fine from one to the other. So, what exactly are you trying to do? What have you tried (except for what’s posted here) and their results?



Error messages? Warnings in log? Anything?

Just make an empty screen to go to…

@madjack I wanted to have independent Nifty instances, just to get rid of the ID collision problem.

Didn’t work, so I guess I’ll use a single Nifty instance and live with the collisions.

@toolforger

I see. Well, I don’t know how you use the screens, but you don’t have to id each and every element in your screen, only those that you need access to. Those that you will call with nifty.findElement(…); and interactive controls like buttons and such). By default, all elements have null as id.



Hopefully that might help to get rid of some of those warnings.

Yes, I’ve been restricting ids as far as possible.



Initially, this sucked greatly for me.

I’m using gettext for translations because the properties way to do i18n cannot properly handle plurals. That means I need to access every element with a text and replace that with its translation - which meant every label needed an id.

Fortunately, I could make use of the Creator classes, where I can insert the strings at creation time. XML proved to be more a problem than a solution anyway :slight_smile:



What remains is event handling. I haven’t found any useful way to tie up events and handlers without using ids.

Why not use this for localization? That’s what I do.

1 Like

It does not properly handle pluralization, i.e. changing words to reflect some number in a message. (I.e. the difference between “1 apple harvested” or “15 apples harvested”.)



For those texts typically found inside a Nifty screen definition, this is not an issue.

However, it would mean property files for screens and .po files for everything else, and translators hate it when they have to deal with multiple message file formats.



See http://unicode.org/repos/cldr-tmp/trunk/diff/supplemental/language_plural_rules.html to see why the typical property file approach to i18n is hopelessly inadequate :wink:

(The first 90% are a table that gives the rulesets for each language, the last 10% are a table that gives the languages for a ruleset.)



I’m using gettext to handle pluralization because I happen to have used it in the past.

I’ve been wanting to try out icu4j, which seems to be better integrated into the typical Java workflow, and also address more languages.

It’s your party man. If the translators can’t deal with it then you’ve got to use workarounds and those can bring you trouble.



There’s always a price to pay. As I said, it’s your party. :wink:

1 Like

Well, I like to make my party attractive to translators.

And my workaround is simple: Use gettext for everything :slight_smile:



I do have to address every string in the Nifty screens, which means using ids if you use XML or the Builder interface, or nothing special if you use the Creator interface.

Fortunately, the Creator interface works best for me anyway :slight_smile:

Well if you were doing layouts in XML you could do a getTranslation(String key) method in the screen controller and call that from the XML. Then you can use any i18n implementation you like in getTranslation.