Nifty is no longer the only choice for creating a GUI within jMonkeyEngine 3, however it is the oldest and the most fully featured GUI library.
[See the full post at: http://hub.jmonkeyengine.org/2013/04/the-herodex-gui-working-in-jme3/]
3 Likes
Interesting read, thanks for this!
hi @zarch :
I 'm glad that your team still choose Nifty over the new rising GUI libs. In fact, Nifty got a lot of potentional on it , the core team was right… I just think because @void do not have enough time to push Nifty further because it’s become big and bigger every release, 
(good and bad).
Lemur and tonegod will also become mature very soon but what if Nifty can also be better.
Now let me explain, some of those will help you guys rethink about Nifty, it’s not OLD:
In Nifty,
-
Event bus intergrated feature is one of those I love the most. It’s simple and effective more and more than Swing style event mechanism.
-
Groovy builder vs Java (verbose) Builder: At my side, i also have few experiments with Groovy builder, so you can use Nifty in Groovy, easy as a piece of cake. You can also subcribe a Closure to Event bus , superb!
-
Nifty Editor: I hope if any chance the current Nifty editor can be merged to JMP. I don’t really know what @relucri trying to do but I think he want to keep it generic as Nifty can be use in various other engines. But if it not into JMP, i’m going to make it! I started doing it today, even @reluci didn’t open source yet but we are all from the same base of pgi’s Editor so…
I hope after all the complains about Nifty, the guys can finally sit back and enjoy it like the old time :p. P/s: If you want to try the Groovy things tell me, just a few line of codes
Thank you! Good article.
Nice and interesting article.
Thanks for taking the time to be so exhaustive about your choices and methods.
I’m really looking forward to the day a great game will come out, and shed some light over jmonkey!
<cite>@atomix said:</cite> hi @zarch : I 'm glad that your team still choose Nifty over the new rising GUI libs. In fact, Nifty got a lot of potentional on it , the core team was right... I just think because @void do not have enough time to push Nifty further because it's become big and bigger every release, :p (good and bad). Lemur and tonegod will also become mature very soon but what if Nifty can also be better.Now let me explain, some of those will help you guys rethink about Nifty, it’s not OLD:
In Nifty,
Event bus intergrated feature is one of those I love the most. It’s simple and effective more and more than Swing style event mechanism.
Groovy builder vs Java (verbose) Builder: At my side, i also have few experiments with Groovy builder, so you can use Nifty in Groovy, easy as a piece of cake. You can also subcribe a Closure to Event bus , superb!
Nifty Editor: I hope if any chance the current Nifty editor can be merged to JMP. I don’t really know what @relucri trying to do but I think he want to keep it generic as Nifty can be use in various other engines. But if it not into JMP, i’m going to make it! I started doing it today, even @reluci didn’t open source yet but we are all from the same base of pgi’s Editor so…
I hope after all the complains about Nifty, the guys can finally sit back and enjoy it like the old time :p. P/s: If you want to try the Groovy things tell me, just a few line of codes
As the article said, at the time we started Nifty was the only option. It’s certainly not a bad option though.
Void is still active, in fact he recently released a massive speed boost for nifty and I saw him the other day talking about the next version which he has some nice plans for.
<cite>@atomix said:</cite> In Nifty, 1) Event bus intergrated feature is one of those I love the most. It's simple and effective more and more than Swing style event mechanism.
I have dug around in Nifty’s code a bit, and found that the advantages of Eventbus go entirely unused by Nifty.
Whatever it is that you love abuot Nifty’s event handling, it’s probably done by Nifty itself, not by Eventbus.
<cite>@toolforger said:</cite> I have dug around in Nifty's code a bit, and found that the advantages of Eventbus go entirely unused by Nifty. Whatever it is that you love abuot Nifty's event handling, it's probably done by Nifty itself, not by Eventbus.
Oh, you should take more time with Eventbus i suggest …
Nifty just subcribe for Event bus’s notification I have to say … If you have use Eventbus in other things like in Web base application or event in Swing, you will see the different.
What i going to tell you that Nifty just used ( may be by intend at the moment ) less then 20% advantages of Eventbus, you don’t really have to tied to MVC or what ever (if you don’t want) in Eventbus Architect, and it’s a good things for GUI Maker. What I found after @pspeed introduce Lemur’s groovy builder is Nifty already have everything to intergrate into the god of GUI (groovy) ;p.
I will give you an example of how short Nifty’s code can be, I think it can compete every other GUI’s libs at the moment!
[java]
package atom.editor.uix;
import com.jme3.system.AppSettings
import java.util.concurrent.Callable
import com.jme3.asset.AssetManager
import com.jme3.app.SimpleApplication
import com.jme3.niftygui.NiftyJmeDisplay
import de.lessvoid.nifty.Nifty
SimpleApplication app = new SimpleApplication(){
Nifty nifty;
public void simpleInitApp(){
NiftyJmeDisplay niftyDisplay = new NiftyJmeDisplay(assetManager,
inputManager,
getAudioRenderer(),
getGuiViewPort());
nifty = niftyDisplay.getNifty();
getGuiViewPort().addProcessor(niftyDisplay);
}
Nifty getNifty(){
return nifty;
}
};
AppSettings settings = new AppSettings(true);
settings.setWidth(800);
settings.setHeight(800);
app.setPauseOnLostFocus(true);
app.setShowSettings(false);
app.setSettings(settings);
app.start();
app.enqueue({
app.flyCam.moveSpeed=20;
app.flyCam.dragToRotate = true;
app.inputManager.mouseVisible =true;
nifty = app.nifty;
def niftyBuilder = new NiftyGroovyBuilder(app.assetManager,nifty);
nifty.loadStyleFile("nifty-default-styles.xml");
nifty.loadControlFile("nifty-default-controls.xml");
niftyBuilder.screen(id:"screen1"){
layer(id:"layer1"){
childLayoutVertical();
(1..5).each{panelIndex->
panel(id:"panel"+"_"+panelIndex){
childLayoutHorizontal();
width("100%");
height("20%");
//backgroundImage("panel/nifty-panel.png")
text(id:"text"+"_"+panelIndex){
style("base-font")
//font("aurulent-sans-16.fnt")
text("Hello"+"_"+panelIndex)
};
button(id:"txt"+"_"+panelIndex,name:"button"){
style("nifty-button")
label("hello")
onClick{
niftyBuilder.("text"+panelIndex).text = "Clicked";
}
};
text(id:"text"+"_"+panelIndex){
style("base-font")
//font("aurulent-sans-16.fnt")
text("Hello"+"_"+panelIndex)
};
}
}
}
}
niftyBuilder.start("screen1");
//nifty.setDebugOptionPanelColors(true);
//nifty.gotoScreen("screen1");
} as Callable)[/java]
[Continue]
And … I can also pick my favorite Frame in a SwingBuilder to make a similar Screen in Nifty Builder as long as I have added enough common components … (which I did!). Hope you guys can see it very good solution for current verbose syntax.
Anyway, it’s Groovy (slow, can not be use in Android)… If you don’t want to leave pure Java at the moment, I have no argument for that.
Spend more time with Nifty - hey, I spent two months digging around in it. That’s more than most people can claim… I might have overlooked things, but never tell me I didn’t spend enough time 
I tried to make a similar builder interface for Nifty, but the generics got too complicated (at least four interrelated generic parameters on most classes, no fun anymore, and also unmaintainable for anybody like Jens who isn’t already fluent with generics).
I agree that Eventbus is a niece piece of work, but I really don’t see any leverage going into Nifty:
- Asynchronous - nope, Nifty explicitly triggers Eventbus to get notifications. It could just as well call the event handler directly - well, maybe it’s Nifty’s way to postpone events triggered during event handling, but a simple Queue would do nicely for that.
- Decoupling - nope, Nifty forces event names. You can’t have a “StartGame” event, it will always be named “layer1.panel_5.startGameButton.clicked” (actual even names may differ).
- Nifty just subscribes - nope, it runs its own Eventbus instance, the application isn’t supposed to feed events to it I think (but haven’t checked).
In my eyes, Jens should simply rip out Eventbus - or allow specifying your own event names, then in fact it would offer some nice decoupling.
That’s just a tangent though; Nifty gets a whole lot of other and more important things wrong. Pushing every property value through a string, supposedly allowing skinning but giving access to almost arbitrary Java code from the XML, lack of Javadoc, overcomplication to the point that control and data flow get hard to follow even for the principal maintainer, a relative (percentage) layout that doesn’t really cover all use cases, far too complicated user-defined controls plus the occasional use case where you absolutely need to do a user-defined one because the standard controls don’t cover all use cases, just off the top of my head.
That said, it does have its good aspects: a readymade skinning system (just treat the XML as part of the code, not as user-modifiable data), a working effects system that manages animations that linger beyond the user interaction (including cancellation of animations for stuff that got removed - that’s not easy to get right), a complete consistent style for all controls.
With the event bus you set the name of the control and then register for the events by control id using either exact match or a pattern. That’s not a forced event name…
Heh, right, I used a hierarchical naming scheme because I wanted to reuse groups of components. Due to the hardwiring, I had to resort to configuring Eventbus without using annotations. (It’s all coming back now…)
Still… the control name is tied to the event name. It’s coupling controls to events - e.g. I can’t have two controls generate the same event.
In other words, whenever the GUI is reconfigured from a text box plus an Enter key to fire off the file name, to a list of file names from which the selection is fired off via double-clicking the name, pressing Enter, or clicking OK, it’s different kinds of events and I can’t wire them to the same event name.
Which, as far as I understand event buses, would be the whole point of having one in the first place.
At least having Eventbus hasn’t created any serious problems, so I’ve been letting it slide.
Anyway, what really made me post is that Atomix claimed that Eventbus has positive effects for Nifty, and I fail to see any.
Am I overlooking something, or is Atomix right?
@toolforger: I don’t have any offensive idea in mind sorry if i sound like so…
Spend more time with Nifty – hey, I spent two months digging around in itIn case you read in wrong , I said :
you should take more time with Eventbus i suggest …I meant if you ever try it in other enviroments you will see the differencies ! ========================================================================================= Ok, and if you did read Nifty code like you said you can see Nifty use the normal Eventbus mechanism! https://github.com/void256/nifty-gui/blob/1.4/nifty-core/src/main/java/de/lessvoid/nifty/Nifty.java
It’s used ThreadSafeEventService ? Normal?
[java]
private void initalizeEventBus() throws EventServiceExistsException {
EventServiceLocator.setEventService(“NiftyEventBus”, new ThreadSafeEventService());
}
[/java]
- Asynchronous – nope, Nifty explicitly triggers Eventbus to get notifications. It could just as well call the event handler directly – well, maybe it’s Nifty’s way to postpone events triggered during event handling, but a simple Queue would do nicely for that.
=====================================================================================================
What kind of affects will happen while Nifty do it? Tell me one example please!
=====================================================================================================
- Decoupling – nope, Nifty forces event names. You can’t have a “StartGame” event, it will always be named “layer1.panel_5.startGameButton.clicked” (actual even names may differ).
=====================================================================================================
It’s a real deal of Decoupling!
now maybe the most common way to trigger Event @void showed it in the documentation is through id, which it’s not really the most ideal way when use Event bus. but there are many other ways :p.
GitHub - google/guava: Google core libraries for Java
Check this one if you didn’t.
I did tell you that if you use Eventbus in a good way, you :
- Don’t have to tied into any kind of specific architecture, say MVC like Swing (in Tonegod’s GUI).
- Can use “soft references” via Id or what ever! <= Nifty provide the most obvious way to do it via Id, you can make another Handlers your self if you want.
- Can use “hard reference”, of course, as in my Groovy builder example (even with Java)
[java]
builder{
label1 = label(text:“I dont have an ID sir!”)
button(id:“button1_blabla”){
label1.text = “Use hard reference is nice!”
}
}
[/java]
And my groovy code is short and super clean, it used mainly the current NiftyBuilder and Creator’s code, nothing real advanced you can tell, in shorter than 300 line of Groovy.
===========================================================================================================
-
Nifty just subscribes – nope, it runs its own Eventbus instance, the application isn’t supposed to feed events to it I think (but haven’t checked).
===========================================================================================================
I can not understand what you want to tell me with this one, of course Nifty use his own Eventbus instance, but the orginal version (same interface, same mechanism) … So?
[java]
public EventService getEventService() {
return EventServiceLocator.getEventService(“NiftyEventBus”);
}public void publishEvent(final String id, final NiftyEvent event) {
// we can’t publish events for elements without an id
if (id != null) {
getEventService().publish(id, event);
}
}public void subscribeAnnotations(final Object object) {
NiftyEventAnnotationProcessor.process(object);
}public void unsubscribeAnnotations(final Object object) {
NiftyEventAnnotationProcessor.unprocess(object);
}public <T, S extends EventTopicSubscriber<? extends T>> void subscribe(final Screen screen, final String elementId, final Class<T> eventClass, final S subscriber) {
if (elementId == null) {
log.warning(“trying to subscribe events for an element with elementId = null. this won’t work. offending class "” + eventClass + “" and offending subscriber "” + subscriber + “". try to find the offending element/control and give it an id!”);
return;
}
ClassSaveEventTopicSubscriber theSubscriber = new ClassSaveEventTopicSubscriber(elementId, subscriber, eventClass);
getEventService().subscribeStrongly(elementId, theSubscriber);
log.fine(“-> subscribe [” + elementId + “] screen [” + screen + “] -> [” + theSubscriber + “(” + subscriber + “),(” + eventClass + “)]”);subscriberRegister.register(screen, elementId, theSubscriber);
}public void unsubscribe(final String elementId, final Object object) {
// This handles direct subscription
if (object instanceof EventTopicSubscriber<?>) {
if (elementId == null) {
log.warning(“trying to unsubscribe events for an element with elementId = null. this won’t work. offending object "” + object + “". try to find the offending element and give it an id!”);
return;
}
getEventService().unsubscribe(elementId, (EventTopicSubscriber<?>) object);
log.fine(“<- unsubscribe [” + elementId + “] -> [” + object + “]”);
}
}public void unsubscribeScreen(final Screen screen) {
subscriberRegister.unsubscribeScreen(screen);
}public void unsubscribeElement(final Screen screen, final String elementId) {
subscriberRegister.unsubscribeElement(screen, elementId);
[/java]
===================================
I DID say that Nifty just use 20% advantages of Eventbus, true! But can you say that Nifty just made up that own event pulishing mechanism not depend on Eventbus?
And with this much of public method, you can direct Nifty to DO almost anything for you!
That’s just a tangent though; Nifty gets a whole lot of other and more important things wrong. 1) Pushing every property value through a string, 2) supposedly allowing skinning but giving access to almost arbitrary Java code from the XML, 3) lack of Javadoc, overcomplication to the point that control and data flow get hard to follow even for the principal maintainer, 4) a relative (percentage) layout that doesn’t really cover all use cases, 5) far too complicated user-defined controls plus the occasional use case where you absolutely need to do a user-defined one because the standard controls don’t cover all use cases, just off the top of my head.==================================================================================================== I think I have to comments a few things about what you said "it's wrong" about Nifty, they are by intended or can be improved, nothing is really wrong, just need time to grow. 1) Property value through String : Give me a bad example of this affect the performance or what ever you thing important. And if you don't like XML, builder, Editor, tell me how you can make GUI????? 2) giving access to almost arbitrary Java code from the XML: This one is bad design I have to agree, the good direction should be reversed, did you ever try Wicket, the Web framework that a Java class choose it's HTML template, that's the good way to do it. Nifty have to change in this one ( it was too depended in XML from the start), but good news is it will get better with an Editor support! 3) lack of Javadoc, ? WTH ... 4) ok, name one! 5) As I said, lack of time in this kind of open source project is the root of every problem. Even when some one start the new one, they will face that problem too...
That’s sad but after all, I have to consider Nifty still the best design GUI, not just in the world of JME, even can compete with some other game GUI of other engines. I also have to said I not very sastified with it even in everyday work but I consider improve it than abandon it. The new rising libs are in very early stage.
Anyway they can get better and better in the future and that’s a good news!
<cite>@toolforger said:</cite> Heh, right, I used a hierarchical naming scheme because I wanted to reuse groups of components. Due to the hardwiring, I had to resort to configuring Eventbus without using annotations. (It's all coming back now...) .......................... Still... the control name is tied to the event name. It's coupling controls to events - e.g. I can't have two controls generate the same event.In other words, whenever the GUI is reconfigured from a text box plus an Enter key to fire off the file name, to a list of file names from which the selection is fired off via double-clicking the name, pressing Enter, or clicking OK,
it’s different kinds of events and I can’t wire them to the same event name.
…
Am I overlooking something, or is Atomix right?
This situation?
============= Copy shamelessly from the Guava link ==================
The EventBus system and code use the following terms to discuss event distribution:
Event | Any object that may be posted to a bus.
Subscribing| The act of registering a listener with an EventBus, so that its handler methods will receive events.
Listener___| An object that wishes to receive events, by exposing handler methods.
Handler method__| A public method that the EventBus should use to deliver posted events. Handler methods are marked by the Subscribe annotation.
Posting an event_| Making the event available to any listeners through the EventBus.
So you want the two GUI action call the same Handler method???
Yes Nifty uses Eventbus.
Just not in a way that actually helps Nifty with anything.
Not sure what you mean about asynchronous issue, so let me clarify:
I spent a good deal of single-stepping through event handling code, and invariably, the event would be constructed, passed to Eventbus, which would instantly call the event handler; asynchronous messaging disrupts any single-stepping debug session, anything cross-thread would have registered in my memory, but nothing of that kind ever happened.
I don’t whether Eventbus does in fact offer a synchronous vs. and asynchronous mode of operation, or is an asynchronous mode, if it exists, is working well or not; I never had reason to check, because, well, Nifty does everything synchronously anyway.
Been there, read the docs on Eventbus (including the Google document).
It’s all about decoupling, but what does decoupling mean?
In my books, it’s making systems so independent of each other that you can modify both without having to change the other.
Despite using Eventbus, Nifty does not really achieve that. Event names are tied to control names (which is bad because controls names cannot always be chosen freely, e.g. internal controls MUST contain a # to separate namespaces, controls that are coded in the GUI xml MUST NOT contain a # to avoid breaking Nifty’s id composing and parsing code).
String property values means that I lose compile-time checking. Had a few cases of needless debugging because the parsing happens very far from the actual bug.
It will also affect performance. It could affect drag&drop since mouse movement handlers can generate quite high event/sec numbers; try this on an Android with a bad GC and the GC churn become noticeable.
I’m not TOO worried about that anyway, the compile-time checking rests far less comfortably with me.
I’m aware of Wicket, and it’s already been near the top of the list of things I’ll try out if I ever get back into the business of coding web pages.
Javadoc helps pinpointing the code block at which things start to go wrong: If a function fails and its preconditions as documented in the Javadoc were violated, you know that the fault lies in the caller and you can stop tracing into the function. This shaves off 90% of debugging-into-the-library time since you can pinpoint the layer of code responsible for a problem very quickly.
Overcomplication: Eventbus, XML as primary style source instead of builders/properties, use of builders to avoid mutable properties which are usually mutable anyway. I think there was more, but I don’t recall enough details.
Yes I want to be able to allow two GUI controls to send the same event.
Imagine a button and a menu item doing the same thing.
Or a more complicated example: Picking from a list. Most people are content with an OK button that does something with the currently activated list item, but I do think the XML maintainers may want to trigger the same event via pressing the Enter or space key, or via double-clicking a list item.
Also, I found I had to recode the Java side whenever I alternated the GUI between buttons, check boxes, and some other variants, but the details are escaping me right now.
Hope this clarifies a few points.
<cite>@toolforger said:</cite> Yes Nifty uses Eventbus. Just not in a way that actually helps Nifty with anything.I still can not agree with this one. It helps but not so much as I mentioned, but "nothing at all" is a very rude way to describe the problem. As @void choose it in Nifty from the start, I really feel its one of favourite GUI lib to work with.
Of cource I can modify it by my self cause it opensourced, but it’s good enough at this state, just improve, not rewrite!
Not sure what you mean about asynchronous issue, so let me clarify: I spent a good deal of single-stepping through event handling code, and invariably, the event would be constructed, passed to Eventbus, which would instantly call the event handler; asynchronous messaging disrupts any single-stepping debug session, anything cross-thread would have registered in my memory, but nothing of that kind ever happened. I don't whether Eventbus does in fact offer a synchronous vs. and asynchronous mode of operation, or is an asynchronous mode, if it exists, is working well or not; I never had reason to check, because, well, Nifty does everything synchronously anyway.As far as I can tell Asynchronous isn't the nature of Nifty execution, that means it's just step-by-step in every steps of operations, so if @void try to rewrite it to support parallel computing, well, that's when Eventbus helps!
Been there, read the docs on Eventbus (including the Google document). It's all about decoupling, but what does decoupling mean? In my books, it's making systems so independent of each other that you can modify both without having to change the other. Despite using Eventbus, Nifty does not really achieve that. Event names are tied to control names (which is bad because controls names cannot always be chosen freely, e.g. internal controls MUST contain a # to separate namespaces, controls that are coded in the GUI xml MUST NOT contain a # to avoid breaking Nifty's id composing and parsing code).The name convention existed in every kind of programming, I really can not see anything related to Decoupling here. I also metion an example use "hard reference". Maybe some other guys have to clarify for me (you know, language barrier) , :p ...
And yes, I used Spring, Wicket, Guice and EventBus (few others)… They provide different ways to decouple things. You just didn’t figure it out, yet!
Now consider Id and ControlName is a MUST in Nifty. It doesn’t matter in EventBus (true!) … I hope you consider read EventBus docs again
http://eventbus.org/api/org/bushe/swing/event/package-summary.html
or try:
nifty.getEventService().subcribe(WhatEverYouLike.class,yourControl);
String property values means that I lose compile-time checking. Had a few cases of needless debugging because the parsing happens very far from the actual bug. It will also affect performance. It could affect drag&drop since mouse movement handlers can generate quite high event/sec numbers; try this on an Android with a bad GC and the GC churn become noticeable. I'm not TOO worried about that anyway, the compile-time checking rests far less comfortably with me.Now I know you want to use it in Android. Yeah. One more time I have to say that Builder over XML is the way!
I work for Gameloft, so you can tell how much I invest into this field. Anyway, consider Builder is the method to build up your GUI, you can take one more look into Nifty code, what activities really time and memory consuming. Not at all?
Not really comforable to say but my company even use SWF to make GUI in Android, they even use ActionScript in runtime… so it’s invalid to tell it’s Nifty’s fault that your application didn’t work in Android, sorry!
I'm aware of Wicket, and it's already been near the top of the list of things I'll try out if I ever get back into the business of coding web pages.Yeah, can not say game programming is easy, or it's a joke :p. As an professional programmer, you can not depend to much in Javadoc or even Documentations... My humble opinion about Nifty docs is it already enough for people to start... As you want to make complicated things, why don't you ask him directly?Javadoc helps pinpointing the code block at which things start to go wrong: If a function fails and its preconditions as documented in the Javadoc were violated, you know that the fault lies in the caller and you can stop tracing into the function. This shaves off 90% of debugging-into-the-library time since you can pinpoint the layer of code responsible for a problem very quickly.
Overcomplication: Eventbus, XML as primary style source instead of builders/properties, use of builders to avoid mutable properties which are usually mutable anyway. I think there was more, but I don’t recall enough details.
Yes I want to be able to allow two GUI controls to send the same event. Imagine a button and a menu item doing the same thing. Or a more complicated example: Picking from a list. Most people are content with an OK button that does something with the currently activated list item, but I do think the XML maintainers may want to trigger the same event via pressing the Enter or space key, or via double-clicking a list item. Also, I found I had to recode the Java side whenever I alternated the GUI between buttons, check boxes, and some other variants, but the details are escaping me right now.Hope this clarifies a few points.
Yeah I’m blunt to the point of rude. One of my numerous weaknesses.
I still fail to see your point though; you’re insisting that Eventbus helps Nifty (fair enough), but I haven’t seen a concrete property named where things work better with Eventbus than they would without, so I still don’t know what value you see in Eventbus.
I agree that Nifty isn’t asynchronous. I’d also say that that’s basically a Good Thing. So we couldn’t agree more on this one.
I mentioned it only because I mistakenly thought you meant to hightlight asynchronouse, thread-based execution support as what Eventbus brings to Nifty. (I believe that Eventbus could in fact bring that, it’s a common thing for event buses to do that; but whatever may be the case here, Nifty doesn’t use it so the point is moot.)
A name convention is of course required, but Nifty imposes restrictions on the names that expose implementation details from XML to Java.
Using Eventbus would be far more useful if event names and control names were fully decoupled.
I did use nifty.getEventService().subcribe(WhatEverYouLike.class,yourControl); That worked fine; it still doesn’t get any value out of Eventbus.
I’m currently not considering rereading the docs. I read them multiple times already, and sucked everything I can suck out of them unless given a specific hint what I might have overlooked. So you’d have to tell me where I’m off the mark before rereading the docs would actually help me gain new understanding.
Ah, Gameloft - nee, ich mach nix für Android
I.e. I am most empathically NOT targetting Android. That’s why I’m not too worried about the conversion overhead and find the loss of compile-time checking more relevant.
I’d probably reconsider if I decided to target Android.
Read the Design by Contract links I gave, then reconsider your stance about Javadoc, please.
I can agree that much Javadoc is useless, but you can use it to good effect if you write them in terms of preconditions and postconditions.
Unfortunately, this isn’t standard practice in the Java world. Some parts of the JDK do it - the Collections framework does, Swing does not.
Most people never experience the raw leverage that extensive precondition/postcondition documentation gives; it needs to be done along all elements of a call chain to be helpful, so I’d say you start to see the benefits if around 50% of the library code used are documented in this way.
nifty.getEventService().subcribe(WhatEverYouLike.class,yourControl);
will solve the situation you want to accomplish, that many specific GUI launch fews kind of Event, but the Control can catch them all at once, via onEvent(EventType) of course.
A name convention is of course required, but Nifty imposes restrictions on the names that expose implementation details from XML to Java. Using Eventbus would be far more useful if event names and control names were fully decoupled.How many restriction in Nifty syntax and naming implemention you can point out? 1 or 2?
I also said that from the beginning Nifty is a “half-assed-solution” that depend 100% in XML, so the naming convention is a legacy and can be wipe out if needed; …but hey, this kind of “#” is the same as “.” in java and provide seamlessly namespace partitioning with one character, even if it’s cause by XML dependant’s root I will keep it, if I have the right to decide!
Now to tell you the true, I DID change a few Nifty classes to leverage Nifty. (like I changed few classes in JME3 to suit my specific silly ambition :p)
Introduce:
- CustomAnotationProcessor to tied every Class-base type to specific Event.
- FilteredElementLinker to tied Conditional matched elements to specific Event…
- CompoundEventHolder to delivery few Event at onces…
( few mores I learnt from the people on wierd wide web when they play with EventBus…:p)
All running through Nifty pipeline easily… cause EventBus and Nifty’s base mechanism to process Elements and Type are already there. Now, ok, you can do all you need with your skilled programming albility and a little bit of imagination.
I don’t see this kind of expandasion is generic enough to be propose to @void, I kept it my self.
In conclusion, don’t hesitate to change the code your self when you need. Then propose to improve if you can and think it’s help people!
Thanks to understand my points and hava a good day,