Tell me about jme GUI libraries, which one is alive yet today?

General Discussion
1

1- NiftyGUI?
2-LemurGUI?
3-Javafx implementation for jme.

I want to know about the support of RTL and UTF-8 encoding and TTF font rendering support in gui controls like labels and text inputs.

2

That’s what I wanted to ask :face_with_monocle:

1 Like
3

My implementation of jfx for jme works fine: GitHub - tlf30/jme-jfx: A up-to-date fork of the jme-jfx library. Compatible with jme 3.4.0 and javafx 12+.

But, I would recommend looking at lemur first. Going down the rabbit hole of jfx is a large project and you should only do it if you need to.

Nifty is dead.

2 Likes
4

Nifty is dead.

I continue to use Nifty in new apps. That makes me an outlier.

I’ve never tried to do RTL or TTF with it.

1 Like
5

Hi @yn97 :slight_smile:

I am using Lemur myself and with a bit of modification, I was able to make RTL works on Lemur as well. You can take a look at my modification here: Added RTL text support. · Ali-RS/Lemur@d264456 · GitHub (I would love to make a PR if the author wants)

Lemur internally uses JME BitmapText and BitmapText does already support RTL.

1 Like
6

I still need to test and apply that patch. Sorry I haven’t gotten to it yet.

Edit: I guess it was never submitted as a pull request?

2 Likes
7

I’m a bit biased because I wrote it… but Lemur is probably the most used and best supported of the JME libraries. It is definitely the only GUI library where you will get tech support directly from the creator.

However, it may depend on what your requirements are. Every library has its weaknesses in JME… Lemur’s is that it currently lacks some features “out of the box” like a proper tree control or “table/data grid” control. (Though a data grid is not too hard to put together after a learning curve.) JME also makes it difficult to have a built-in “scroll pane” that works like most other GUIs. You can simulate it with viewports but it’s hard to build in as a standard component because of all of the caveats I’d have to include.

But what you get is a GUI library that directly integrates with JME’s scene graph because Lemur’s GUI components are actual JME Spatials. It also supports fully 3D GUIs, can treat any JME model like a button, etc… It can also project 2D UIs into textures and with a little effort already has support for receiving clicks/mouse gestures through that texture. (Lemur also supports multi-touch out of the box… ie: you can drag a slider with one finger and a different slider with another finger.)

On the other end, Java FX has every UI thing you’d ever want but is trickier to integrate and will always have a performance penalty for the screen copy. I feel like Java FX is always treated as a “second class” UI in the Java world because it was never fully integrated in the JDK… but that could be me long-standing Swing-bias that makes me feel that way.

If you were going to be making some highly stats-driver RTS with tons of windows and nested data grids, etc… Java FX would be pretty attractive.

So in the end it will depend a little on what you want to do.

(Note: Lemur may get a proper Table/DataGrid control soon because it’s the one I constantly miss and is relatively easy to put together. A tree control is another one I constantly miss but is much harder to do properly and I always end up finding a different way to do that kind of UI.)

2 Likes
8

Yeah, no PR is submitted (I think back then when I made the patch JME 3.5 was not released yet. Note that this change will require JME v3.5), I have only submitted a GitHub issue but please let me know if the changes sound good to you and I will submit a PR.

Edit:

Link to the issue just in case:

Edit2:

And, well, I would say my patch is more like a hack :wink:

1 Like
9

I mean, yes and no. Your patch is very straight-forward and probably the only way to do it without a total DocumentModel refactoring to make “forward/back” an abstract concept independent of left/right.

The thing I liked about your patch is that it’s surgical and does not at all affect regular LTR text.

Honestly, that’s the only thing I don’t like about it but it’s probably time for Lemur to advance. Just a shame because it was kind of neat that the latest Lemur could still work with so many versions of JME.

…but in the end, it’s inevitable to move forward.

Edit: and I know the RTL stuff requires the upgrade… so it isn’t like you had a choice about that.

2 Likes
10

Heheh… another point “in favor” of Lemur is that you will likely not get actual contributors hijacking your JME threads for JavaFX or Nifty development discussions. :slight_smile:

3 Likes
11

I also prefer Nifty for some applications (simple HUDs, basic menus and title screens that don’t look like a desktop app). But I prefer Lemur when I have many panels with text fields and buttons, etc (also making any scene geometry interactive is a great reason to use it).

2 Likes
12

And for that part, it need not be “either or”… you can use that part of Lemur and still use nifty for GUI stuff.

Really there are many good reasons to have Lemur in your dependencies even if you don’t ever popup a Lemur GUI element.

2 Likes
13

Forgot to mention this earlier, JME font does not support TTF fonts so you need to convert them to bitmap font. You can use this tool to convert them BMFont - AngelCode.com

Also, note for cursive text (like Persian and Arabic) you need to specify a GlyphParser:

We have one for Persian but it can be used for Arabic as well because glyph codes are mostly the same. (at least they were when I checked with the “B” fonts family)

2 Likes
14

What about this? https://1337atr.weebly.com/jttf.html

EDIT: It would not work in combination with the mentioned UI libraries but it’s the best way to render TTFs with jME (never tried it myself).

3 Likes
15

Late to the party here but figured I’d chime in.

I’ve used JavaFX as a fullscreen UI overlay for the MyWorld client for several years. Unfortunately, it’s not a well behaved citizen speed-wise - the multi-stage copies that it has to do add a lot of latency to the UI, and then the GPU->CPU->GPU copy penalize you further. The UI ends up feeling very sluggish and slow overall. It’s very disappointing because otherwise JavaFX is an amazing toolkit - it’s just not designed for efficient embedding and the only way around that is some very involved low-level work (I believe it could be done with a custom Glass implementation, but that’s quite involved and I suspect likely to break easily between JavaFX versions).

3 Likes