It’s been a while since many of my open source libraries have been released… even though many have lots of changes since the last release.
Today I start a week long vacation and plan to spend the first 1-2 days checking problem reports, applying patches, etc. to get these ready to rebaseline everything.
So… if you have a pet issue that you want to remind me about then now/here would be the best time.
Thanks.
You already saw this about the PM,
Yes, thanks. Ironically, I might not have found it if you hadn’t mentioned… because I originally forgot to check PMs. D’oh.
I have some to remind you 
Before that, I want to first give my special thanks for all of your useful libraries you created for jme. I am using most of them in my game (which had been abandoned for about 17 months due to my mandatory military service and now that I am done with my military service I am back to work on it again).
Here is the list of issues/feature requests I have reported
https://github.com/Simsilica/SiO2/issues/8
https://github.com/jMonkeyEngine-Contributions/Lemur/issues/63
https://github.com/jMonkeyEngine-Contributions/Lemur/issues/59
https://github.com/jMonkeyEngine-Contributions/zay-es/issues/16
https://github.com/jMonkeyEngine-Contributions/Lemur/issues/52
From the things that were on my mind recently, what about the following points in general? I know it may call for much more time than a couple of days, but since you’re asking:
Officially include a way to implement elements clipping. For example, incorporating a ViewportPanel would do. There is a currently available contribution from @NemesisMate, it is very useful but it comes with its own rather big library with lots and lots of code. It would be nice to have this particular feature finely-cut natively in Lemur. Here is the related thread: Sharing of debug & lemur utils
A related issue is the absense of an easy way to create scrollbars for the clipped area (there is no such issue currently in Lemur because there’s no clipping). Currently there is a way to use sliders for it, but I would vote for a more explicit way to add and unilize scrollbars. For example, there’s one hardcoded and baked-in in the ListBox class, but I think it should be a separate class with a well-defined interface. It could be an extension of Slider just as the Button is an extension of the Label, and just as easy to add/remove and configure.
The above two points converge on the one I’m actually trying to convey: add a built-in concept of a window. One of the first things working with a GUI library is to expect it to allow creating windows. That may be not so true when you think of many of game GUIs, but for example Nifty has it, and definitely there are games that can make a good use of windows. And a window draggable by a title bar (Draggable Window in Lemur) would be a very welcome addition.
What about incorporating TrueType support as a part of Lemur or an official plugin? There is a Lemur fork from @Tryder which is great, but it is based on an older Lemur version and introduces breaking changes to it. Here is the thread we had on it: Lemur texts and fonts (Lemur + JME-TTF ?) - #9 by noncom
Expose word wrap modes for the text (were talking about it here Word wrap in Labels etc - #21 by noncom)
Fill in the absent wiki sections, like:
I’m not sure how much the points 1-4 are relevant, but them are what I constantly think of when working with Lemur. Since I was doing a forum research on this, I find that the topics are pretty recurring, so it might be a good idea to deal with them. This might not be a simple work for a day or two, but I would like to know what you think of these points. And if you approve the concepts then even if you won’t have time to work on them in the near-term, a contribution from me or other forum members is possible.
FYI: sliders are scroll bars. I just called them Slider is all.
I’ll see what I can do to address some of the others. A ViewPort example has been on my list for a while.
TextField key listeners issue with LWJGL3 :
Switching to LWJGL3, TextEntryComponent actions like BACKSPACE, RIGHT, LEFT, DELETE are not working when you press and hold them.
But space bar is working correctly. It seems you are handling space key action differently.
Another issue,
Putting two ListBox together inside a Container, clicking on the list box elements will not work.
The only way I could make it work is to add BorderLayout to container, and add one listbox to east, and other one to west.
Container listBoxContainer = prefabTab.addChild(new Container(new BorderLayout()));
listBoxContainer.addChild(new ListBox(new VersionedList<>(collections)), BorderLayout.Position.West);
ListBox<PrefabModel> objectList = listBoxContainer.addChild(new ListBox<PrefabModel>(new VersionedList<PrefabModel>()), BorderLayout.Position.East);Nope… all on LWJGL. (Or possibly JME’s integration with it).
For spaces JME is sending me multiple down events and for the others it isn’t.
The thing is, I can’t really properly handle repeats on my own because I don’t have a way to query the OS’s repeat delay and frequency. It seems like LWJGL (or JME) is swallowing the extra events that the OS is sending.
Starting to think JME should go directly to AWT for this because LWJGL seems messed up with input.
Is it possible to get a non-working example as well as the working one?
…in a github issue if you are feeling extra generous. 
I’ve got new versions of:
zay-es
zay-es-net
sim-math
sio2
…basically ready to release.
I will wait until after I’ve slept because it’s probably a good idea to make one more pass with rested eyes.
The rest of the day will be Lemur-related.
Edit: but if anyone builds from source on those other projects, now is the time to update to see if something breaks. 
With respect to what’s going on with the second viewport.
I am wondering if this isn’t a jme bug with this method,
When this constructor for a new camera is called,
it sets only the width and height plus defaults then calls onViewPortChange(),
which calls setGuiBounding().
Same thing happens with setViewPort(),
Same thing happens with resize(),
When you look at setGuiBounding,
it calculates the bounding box but nothing ever resets width and height to match the new viewport so whenever getWidth() or getHeight() gets called its always the size of the original width and height.
Maybe I am wrong but shouldn’t this method do this after the last line?
width = ex - sx;
height = ey - sy;
I created a test and I can successfully catch repeating key events running on lwjgl3. Seems should not be a problem with lwjgl3 side ?
import com.jme3.app.SimpleApplication;
import com.jme3.input.RawInputListener;
import com.jme3.input.event.*;
import com.jme3.ui.Picture;
public class TestGlfwKeyInput extends SimpleApplication {
private RawInputListener inputListener = new RawInputListener() {
public void beginInput() {
}
public void endInput() {
}
public void onJoyAxisEvent(JoyAxisEvent evt) {
}
public void onJoyButtonEvent(JoyButtonEvent evt) {
}
public void onMouseMotionEvent(MouseMotionEvent evt) {
}
public void onMouseButtonEvent(MouseButtonEvent evt) {
}
public void onKeyEvent(KeyInputEvent evt) {
if (evt.isRepeating()) {
// works just fine
System.out.println(evt.toString());
}
}
public void onTouchEvent(TouchEvent evt) {
}
};
public static void main(String[] args) {
TestGlfwKeyInput app = new TestGlfwKeyInput();
app.setShowSettings(false);
app.start();
}
@Override
public void simpleInitApp() {
inputManager.addRawInputListener(inputListener);
}
}
I looked at TextEntryComponent class but do not see anywhere you are mapping the space key, where are you doing the mapping and how does it work ?
I tried to create test case, but it seems every things works fine in test. So something should be wrong in my code.
The problem is that when I am adding second listbox, the click command on my firstbox (which I added using listbox.addClickCommands()) is not get called but yet the selected item will get highlighted.
Later I will try to take a deeper look to see what cause this in my code.
TextEntryComponent adds a general key listener to the KeyInterceptState or whatever… which is essentially forwarding raw event from the InputManager.
They end up in the KeyHandler:
You see there is no special handling for one key or another… just look up the right action and run it. Maybe lwjgl stops sending the key char for things other than space?
Not sure. When I played with this stuff before, I got the impression that width/height should always be the ‘display’ width and height as everything else is calculated from them.
Even in the code you posted, if width and height were reset then every time setGuiBounding() was called, the viewport would get smaller and smaller as sx, ex, etc. would all be recalculated against the new smaller width/height…
Hmm, I think I found the bug, as you said it seems to be a bug with lwjgl.
for following
public void onKeyEvent(KeyInputEvent evt) {
if (evt.isPressed()) {
System.out.println(evt.toString());
}
}
For any key I press and hold I will get 0 key code as result :
Key(CODE=0, CHAR=s, PRESSED)
Key(CODE=0, CHAR=s, PRESSED)
Key(CODE=0, CHAR=s, PRESSED)
Key(CODE=0, CHAR=s, PRESSED)
Key(CODE=0, CHAR=s, PRESSED)
Key(CODE=0, CHAR=d, PRESSED)
Key(CODE=0, CHAR=d, PRESSED)
Key(CODE=0, CHAR=d, PRESSED)
Key(CODE=0, CHAR=d, PRESSED)
Key(CODE=0, CHAR=d, PRESSED)
Key(CODE=0, CHAR=d, PRESSED)
but see this one
public void onKeyEvent(KeyInputEvent evt) {
if (evt.isRepeating()) {
System.out.println(evt.toString());
}
}
this will return correct key code
Key(CODE=31, REPEATING)
Key(CODE=31, REPEATING)
Key(CODE=31, REPEATING)
Key(CODE=31, REPEATING)
Key(CODE=31, REPEATING)
Key(CODE=31, REPEATING)
Key(CODE=32, REPEATING)
Key(CODE=32, REPEATING)
Key(CODE=32, REPEATING)
Key(CODE=32, REPEATING)
Key(CODE=32, REPEATING)
Key(CODE=32, REPEATING)Yes. I am terrible at explain things but I will give it a shot.
What I am seeing as a problem is that the way this is designed, if you setViewport(), it resizes the viewport based off width/height, which was the original settings at startup.
After resizing, the viewPortLeft, viewPortRight, etc. variables all are matching the values set with setViewport but it does not reset width / height and there is no way to do so.
If you call new Camera(x, y) constructor instead, it uses x, and y but sets all the variables viewPortLeft, viewPortRight, etc to default 0, 1 etc. and properly resizes everything but since it set the viewPortLeft, viewPortRight, etc variables to default numbers 0,1, the viewport sits at the bottom-left corner of the screen.
All your code works perfectly in this viewPort. Problem is, if you want the viewport to be drawn anywhere else except from bottom left 0,0 you cant move the viewport. I don’t see any way to move it from bottom left.
I am probably doing something wrong in setting up a camera is all I can figure but that viewport created by the constructor does work exactly like it should, it reports the proper width / height, and the buttons scale and listeners fire properly.
I am going to redo my minimap camera from scratch and see if I can make it work.
There is a separate event for pressed and repeating? like, two events for every repeat?
…super weird. Repeat implies pressed.