"Roll Your Own" GUI (Update: Fully Integrated Texture Atlas... finally)

You people have all the power, problem is you’re all short-sighted gits :wink: :wink:

@normen said: You people have all the power, problem is you're all short-sighted gits ;) ;)

Lol… and I thought no one would notice :wink:

I’ll tell ya what. I’ll sum up few last things and then add this to the repository for other contributors to start… contributing to. If you go through the source code, I have a feeling that you’ll be pretty happy with how this was implemented as it uses all standard JME3 components (Controls, Nodes, Geometries, Meshes). I was careful to not overload the application with a million controls… the screen class is the only control by default… and buttons register themselves as controls ONLY if they implement mouse still down interval behavior).

The only um… eh… monkey-business in the project at all, is I unregister the font loader and replace it with one that uses my modified version of the Unshaded shader so I could implement layer clipping on text as well as elements. I ended up using this for handling textfield needs and will implement effects this way as well.

Anyways… I don’t want to be the only person working on something like this, however… this just happens to be an area that I have YEARS (more than I would like to admit) of experience in.

Well all the better, its just that I will direct all raging monkeys to you until we can really adopt this as a second way to do UI :stuck_out_tongue_winking_eye:

@madjack said: Screw the powers-that-be. ;)

Pet peeve: I really hate it when devs don’t implement CTRL-INS / CTRL-DEL, effectively the precursors of Copy/Paste modern shortcuts of CTRL-C/CTRL-V.

Also, word navigation in an editable text box can be frustrating. Firefox uses its own version of how that should work vs standard software. But that part is very rare.

As far as the GUI library is concerned, if I were a religious type I would constantly pray for your salvation. :stuck_out_tongue: lol

Word navigation is implemented the same as text ranges (this is for single line text fields).

Arrow left : previous character
Arrow right: next character
Arrow up or Page up or Home : beginning of line
Arrow down or Page down or End : end of line.
CTRL + arrow left : previous word
CTRL + arrow right : next word.

Add the SHIFT Key and your selecting text same as above.

If I get around to converting the text field to multi-line with wrap + scrolling… arrow up & down, page up & down, home & end will work as expected.

Oh and I’ll ad in CTRL+INS, CTRL+DEL for cut/paste … been a while since I have used these.

@normen said: Well all the better, its just that I will direct all raging monkeys to you until we can really adopt this as a second way to do UI ;P

That’s fair enough. :slight_smile:

1 Like

On the one hand, Lemur uses action maps kind of like swing. The key binding can be done in whatever way to call whatever actions.

On the other hand, Lemur doesn’t implement some things like selection or cut and paste because I don’t need it. :slight_smile:

Still, the idea of action maps is a good one. In general swing is one of the best written UIs and it pays off to borrow the good ideas.

@t0neg0d said: Word navigation is implemented the same as text ranges (this is for single line text fields).

Arrow left : previous character
Arrow right: next character
Arrow up or Page up or Home : beginning of line
Arrow down or Page down or End : end of line.
CTRL + arrow left : previous word
CTRL + arrow right : next word.

Add the SHIFT Key and your selecting text same as above.

If I get around to converting the text field to multi-line with wrap + scrolling… arrow up & down, page up & down, home & end will work as expected.

Oh and I’ll ad in CTRL+INS, CTRL+DEL for cut/paste … been a while since I have used these.

Nice nice. Me like.

FWIW, arrow up/down should place the caret at the same position on the line above/below if there are enough characters. If not, caret should be placed at the end of the line.

Also, if you do implement wrapping text area, CTRL-UP/DOWN should move the caret to either the first character of the current paragraph, or the last character of the paragraph or (if you’re already at the first/last char.) move to the last char of the previous paragraph or the first char of the next paragraph. Hopefully that will make sense to you.

Finally, word navigation… That’s a tough one. The main question is, how do you handle punctuation? There are many school of thoughts on the subject sadly. I personally think selection should stop before the punctuation, not after. Ex. phrase: “This, is a test.” If I use CTRL-RArrow on “This” I should end up having “This” highlighted and not "This, " as Firefox would make it. Selection implies correction and usually it’s to correct the word… Anyway, I think the best bet is to fire up a word processing software and see how these handle it, those would be the best examples to follow IMO. Just don’t follow FF’s awful ways. :wink:

@normen said: Well all the better, its just that I will direct all raging monkeys to you until we can really adopt this as a second way to do UI ;P

What. Ever! :stuck_out_tongue:

What you fail to realize (or you simply ignore, or I wouldn’t put it past you that you’re just trolling) is that 90% of users either hate or dislike Nifty and would rather eat raw Brussels sprouts for a week than bang their heads on their desk trying to have Nifty behave right. In short, they’d rather use anything but Nifty.

What I see here is @t0neg0d and @pspeed (in his own thread) making an alternative to Nifty. The way I see it, everyone wins, maybe except you because you didn’t get your way. :stuck_out_tongue: For once. Double :stuck_out_tongue: :stuck_out_tongue:

Kidding aside, as long as Paul and Scot support their lib (which I’m sure they will as long as they hang around here) not only they build something great, but we, as a community win BIG time as this could be considered a lot more native to jME than any other implementation coming from the outside.

Actually, I think @normen 's point is more than well founded. Having a few options that others can contribute to and build off of might not be so bad… but if 50+ people run off in different directions and that number just grows and grows… it would be total chaos.

Louis, less talkie… more fetchie… Here is a vid of the text field stuff:

[video]http://youtu.be/bYt8pKBT3es[/video]

Oh…though I would throw out a quick usage demo: Some of this will change… as styles will (at a minimum) will be definable via XML.

From any JME Application or AppState
[java]
// Create the screen
screen = new Screen(this);
screen.initialize();
guiNode.addControl(screen);

// Add controls - constructor is identical in all controls as it is the only info required to function. Controls preset behavior settings. Optional data can be added after.
Window win = new Window(
screen, // The screen control
“Window”, // A unique id
new Vector2f(150, 125), // position relative to container parent – in pixels
new Vector2f(300, 250), // Dimensions - in pixels… getting the idea?
new Vector4f(14,14,14,14), // Resize border (this is not required in overloaded constructor as it is pulled from style info)
“Textures/panel_x.png” // Default image (Also not required in overloaded constructor as it is pulled from style info)
);
// Set some optional behavior
win.setLockToParentBounds(true); // will only move & resize within parent containers dimensions
win.setResizeN(false); // can no longer resize by north border (NW, NE will only function as W, E)
win.setClippingLayer(win) // The text element of the primitive will now be clipped by win
win.setTextPadding(4) // The text element of the window primitive element will now be padded by four pixels.
// etc, etc, etc.

win.addChild(some other control);

screen.addElement(win)
[/java]

And literally (aside from behavior setting methods… which are common and well documented) this is all you need to know to create entire UI’s.

Looks interesting, good job =)

1 Like

Sounds like t0neg0d and pspeed need to combine their stuff together so we get a resulting super-duper gui lib :slight_smile:

I think one alternative to nifty would be good. Two alternatives is already too many though :wink:

1 Like
@madjack said: What. Ever! :P

What you fail to realize (or you simply ignore, or I wouldn’t put it past you that you’re just trolling) is that 90% of users either hate or dislike Nifty and would rather eat raw Brussels sprouts for a week than bang their heads on their desk trying to have Nifty behave right. In short, they’d rather use anything but Nifty.

What I see here is @t0neg0d and @pspeed (in his own thread) making an alternative to Nifty. The way I see it, everyone wins, maybe except you because you didn’t get your way. :stuck_out_tongue: For once. Double :stuck_out_tongue: :stuck_out_tongue:

Kidding aside, as long as Paul and Scot support their lib (which I’m sure they will as long as they hang around here) not only they build something great, but we, as a community win BIG time as this could be considered a lot more native to jME than any other implementation coming from the outside.


You just had to make it a loud revolution instead of a silent one eh? Hope you’re not superstitious but I guess that wasn’t too good.
I certainly don’t ignore that many people have issues with Nifty but its only those that get vocal about it coming to the forum so I don’t think the number you pulled out of your ass is realistic. I also don’t know when I ever got my way with the engine, I always get Kirills and then get ridiculed for defending it so that at least something happens. Thats bad enough, I don’t want to pick up random peoples problems too. And I know how much it sucks to support a library that you don’t even use yourself cause your game project is over for a while already, few people manage that and I’d not include you in that group for example. For t0neg0d I don’t know yet but nobody gains when we have a UI system that can make nice resizable windows but not much else while she’s up to do new things and can’t be contacted. Jens gave lots of support here and continuously fixes issues with nifty, some of the issues left are on the engine side and not really in his reach.

@normen said:
@madjack said: What. Ever! :P

What you fail to realize (or you simply ignore, or I wouldn’t put it past you that you’re just trolling) is that 90% of users either hate or dislike Nifty and would rather eat raw Brussels sprouts for a week than bang their heads on their desk trying to have Nifty behave right. In short, they’d rather use anything but Nifty.

What I see here is @t0neg0d and @pspeed (in his own thread) making an alternative to Nifty. The way I see it, everyone wins, maybe except you because you didn’t get your way. :stuck_out_tongue: For once. Double :stuck_out_tongue: :stuck_out_tongue:

Kidding aside, as long as Paul and Scot support their lib (which I’m sure they will as long as they hang around here) not only they build something great, but we, as a community win BIG time as this could be considered a lot more native to jME than any other implementation coming from the outside.


You just had to make it a loud revolution instead of a silent one eh? Hope you’re not superstitious but I guess that wasn’t too good.
I certainly don’t ignore that many people have issues with Nifty but its only those that get vocal about it coming to the forum so I don’t think the number you pulled out of your ass is realistic. I also don’t know when I ever got my way with the engine, I always get Kirills and then get ridiculed for defending it so that at least something happens. Thats bad enough, I don’t want to pick up random peoples problems too. And I know how much it sucks to support a library that you don’t even use yourself cause your game project is over for a while already, few people manage that and I’d not include you in that group for example. For t0neg0d I don’t know yet but nobody gains when we have a UI system that can make nice resizable windows but not much else while she’s up to do new things and can’t be contacted. Jens gave lots of support here and continuously fixes issues with nifty, some of the issues left are on the engine side and not really in his reach.

Like I said, I understand your reservations… and agree. However… the library Currently consists of a whooooooole lot more than resizable windows. Here be the breakdown:

Form controls:
Buttons (3-state + interval or toggled )
Checkbox groups
Radio Button groups
Sliders (notched or free-floating / vertical or horizontal)
Spinner controls (vertical or horizontal)
Text Field
Password field
Drop-down list (with resizable scrollable list)
Combo Box (with resizable scrollable list)

Menuing:
Menu bar
Menus (Nested submenus… + dynamic state change for reusable right-click menuing)

Scrolling:
Scroll panel
Scroll area
Vertical scroll bar
Horizontal scroll bar

Windows:
No-dragbar resizable/movable panel
Standard Window
Alert Box
Dialog Box
Login Box

Latest edition:
Styles! Finally figure out how I wanted to implement them. I took a VERY open-ended approach using XML… however, the system dictates almost nothing to you… you can create any type of attribute you want… it just requires that you define the data type so it can be returned to you properly.

[java]
<element name=“Window”>
<attributes>
<property name=“resizeBorders” type=“Vector4f”>
<x value=“14” />
<y value=“14” />
<z value=“14” />
<w value=“14” />
</property>
<property name=“minSize” type=“Vector2f”>
<x value=“150” />
<y value=“50” />
</property>
<property name=“defaultSize” type=“Vector2f”>
<x value=“350” />
<y value=“200” />
</property>
</attributes>
<images>
<property name=“defaultImg” type=“String” value=“Interface/Window/panel_x.png” />
</images>
<effects>
<property name=“hide” value=“fade” speed=“3” />
<property name=“show” value=“fade” speed=“3” />
</effects>
</element>
[/java]

There is also a section for fonts… but for now… it work as such. The parse reads in all the styles. To retrieve them, you simply use:

[/java]
screen.getStyle(“Window”).getVector4f(“resizeBorders”);
[/java]

This way, if someone decides to develop a new control, they can easily implement a style without constraints imposed by me.

2 Likes

For some reason I can’t thumb your post but thats very cool :slight_smile: In theory we should be able to use and edit this in the SceneComposer too, we’d just need to be able to access the GUI node to attach these, right?
Btw, I know you understand me, its just that especially with @madjack here I already had a discussion about the engine, nifty and me.

@normen said: Btw, I know you understand me, its just that especially with @madjack here I already had a discussion about the engine, nifty and me.

Actually, our discussion was more about Void and Nifty and me implementing TWL’s library for jME, but that’s not important.

What IS important is that I pushed my little joke a farther than I should have and I apologize for it.

On the old site we had the tag list on the bottom right and Nifty was probably the highest usage word, which indicates it was used a LOT. This showed that a majority of problems were pointing to Nifty. It certainly wasn’t about how easy it is to use and how great the end results can be (which CAN be great looking). Many people post here because they have problems. The simple trend was (and still is) that Nifty is a problem in itself. I’m sure that didn’t escape notice on you guys.

There is no denying Nifty is a powerful GUI system, but power is irrelevant if the learning and usability curve are steeper than the engine, game programming and math combined (yes, I’m exaggerating). Nifty is bloated, not very user friendly, lacks documentation and is infuriating to use for a long while. I will agree that the Nifty bible helped many users, but it also missed the mark on several key points for more advanced users.

Honestly my wish for 2013 is that jME drops Nifty completely and adopt either Scot or Paul’s library. Because in the end it’s better for jME if the majority of the posts are about the engine, not the GUI lib it uses.

1 Like
@madjack said: Actually, our discussion was more about Void and Nifty and me implementing TWL's library for jME, but that's not important.

What IS important is that I pushed my little joke a farther than I should have and I apologize for it.

On the old site we had the tag list on the bottom right and Nifty was probably the highest usage word, which indicates it was used a LOT. This showed that a majority of problems were pointing to Nifty. It certainly wasn’t about how easy it is to use and how great the end results can be (which CAN be great looking). Many people post here because they have problems. The simple trend was (and still is) that Nifty is a problem in itself. I’m sure that didn’t escape notice on you guys.

There is no denying Nifty is a powerful GUI system, but power is irrelevant if the learning and usability curve are steeper than the engine, game programming and math combined (yes, I’m exaggerating). Nifty is bloated, not very user friendly, lacks documentation and is infuriating to use for a long while. I will agree that the Nifty bible helped many users, but it also missed the mark on several key points for more advanced users.

Honestly my wish for 2013 is that jME drops Nifty completely and adopt either Scot or Paul’s library. Because in the end it’s better for jME if the majority of the posts are about the engine, not the GUI lib it uses.

At the same time its the best example of how it benefitted from general use as by now theres been a ton of bugs fixed and features added, lots of documents written and lots of snippets being created. All the Nifty UIs I see in games work fine and look great. We certainly won’t drop Nifty altogether and it will remain a first class citizen in jME as many games and projects already use it successfully and depend on it. What you say just isn’t universally true and again trying to force it this way is the completely wrong way.

Is it already somewhere as an Download to test it? I think not only me cant wait to try it out.

About the Nifty Discussion: I have a big Problem that Nifty always loose Focus when i drag/rotate the Camera (in this application you can see in the screens http://hub.jmonkeyengine.org/forum/topic/solved-controlling-a-simpleapplication-by-keycommands-for-fullscreenmode-from-the-embedded-swing/ ) .

Try to fix it since almost 10 Month. Maybe its possible to fix, but i am just soo tired about it already.

@normen said: At the same time its the best example of how it benefitted from general use as by now theres been a ton of bugs fixed and features added, lots of documents written and lots of snippets being created. All the Nifty UIs I see in games work fine and look great. We certainly won't drop Nifty altogether and it will remain a first class citizen in jME as many games and projects already use it successfully and depend on it. What you say just isn't universally true and again trying to force it this way is the completely wrong way.

There’s no denying it improved. There were two ways Nifty development could go, up or extinct. I -am- happy it didn’t go belly up as I am also a user because the alternative would have meant I would have had to make a GUI myself. I’ve got other things to do. This is exactly why I use jME. I want to focus on making a game, not an engine. I want to use a GUI, not make one.

I would be really curious if every user were polled on the Nifty subject. How many have called it quit because of it? Or moved on to a different engine? I stuck with it because there were no alternative and I’m bull-headed but not everyone is willing to go through that.

Anyway.

We’re arguing on nothing relevant here. Paul and Chris (Why do I call you Scot Chris is beyond me! O_o) are working on a GUI implementation and I’ll gladly switch to whichever I prefer when they’re “released” into the wild without a second thought and absolutely no regret.

Nifty has given me enough grief. I’m not willing to put up with it more than I will have to.