@madjack said: setText(..) is a Spatial method... I don't think it would be a good idea to suggest making that protected or package specific...
The setText method is defined in the tonegod.gui.core.Element class.
AFAIK you cannot change the visibility of a method by overriding it.
@kwando said: ALT + Left/Right => jump to next/prev delimiter (white space, punctuation signs etc) ALT + Up or CTRL + Left => Home ALT + Down or CTRL + Right => EndAh… I did not read the documentation =P I just though the setText method was supposed to change the text. Sorry about that. Change the name of it to something more cryptic or change the visibility (maybe package visibility?) of the method. Ideally non public / internal methods should not be invokable by user code.
Maybe it is time that the bugs are kept on a issue tracker so we can spend our time being productive instead of making double work like this
I recommend hosting open source projects on github (you will get a neat little issue tracker).
I have resolved the setText issue. After tonight’s patch setText can be called directly. I apologize for the confusion with this one, as this should have been the case from the start. setTextFieldText can still be used, however it now just forwards to setText.
I currently track issue HERE. Everyone can feel free to add issues there if they want. You can also grab the latest commits there if you don’t want to wait for the JME nightly build.
@madjack said: At a quick glance I couldn't find a way to get that info, but I wonder why you need to know this?
Not sure I do need to know this, as I haven’t tested how the number pad interacts when num lock is on/off yet. But, this is something I’ll be looking at today. If different key codes are sent depending on the state of the num lock key, then I really don’t need to be aware of this.
However… the current state of the insert key… is this application specific? i.e. I open notepad and word (for instance)… I hit the Insert key while in notepad. Are other applications aware of the current Insert state? Or just the focused app? Never really thought of checking to see how this works until now.
Caps lock and num lock are global afaik. I have -never- seen anything pointing against that in 20 years, but I’ve been proven wrong before. shrug
So, if you get an INSERT, it could either be from the keypad (KEY_NUMPAD1 while numlock is off) or the “real” Insert key. Which mean you shouldn’t care from which it’s generated from. If you get a KEY_NUMPAD1 key then NUMLOCK is on. I can’t say I’ve tested this though.
@kwando said: The setText method is defined in the tonegod.gui.core.Element class.
My bad. Got mixed up with something else.
@madjack said: Caps lock and num lock are global afaik. I have -never- seen anything pointing against that in 20 years, but I've been proven wrong before. *shrug*
I have assumed that this is this case with JME as well. I know this is true with Caps Lock, however… I haven’t checked with Num Lock. I would be stunned if this was not the case here as well–thus the reason for not having checked it yet.
As for the Insert key. Do you know if this is a global setting? Or is it application specific? And, do you think it is important that this functionality be part of the TextField class? Personally, I rarely use the Insert key (if at all) just due to the easy of using text ranges for removing text. Insert + command line always made sense, otherwise… I have no clue whether people make use of this regularly. Thoughts?
@t0neg0d said: I have assumed that this is this case with JME as well. I know this is true with Caps Lock, however... I haven't checked with Num Lock. I would be stunned if this was not the case here as well--thus the reason for not having checked it yet.As for the Insert key. Do you know if this is a global setting? Or is it application specific? And, do you think it is important that this functionality be part of the TextField class? Personally, I rarely use the Insert key (if at all) just due to the easy of using text ranges for removing text. Insert + command line always made sense, otherwise… I have no clue whether people make use of this regularly. Thoughts?
Honestly the only times I use INSERT is by accident. I have no idea why this key still exist in modern computers except maybe for some backward compatibility thing with extremely old software / hardware.
The current committed version of TextField:
DELETE key working
Double-click text range selection in empty field will no longer set the caret index improperly and cause an IndexOutOfBoundsException when typing after the fact.
Double-click will now properly selected the last work in the string
Using CTRL+Arrow Left no longer selects the space to the left of the word.
The visual placement of text ranges no longer appears to contain the space before the word when it does not.
Gripes time! 
I can’t seem to get my preview to work. -.- Probably me…
Here’s what I’m doing.
In the class constructor:
[java]
createOSRScene();
rightPreview = createRightPreview();
rightPreview.hide();
[/java]
Here’s the OSR’s method (tame stuff):
[java]
private void createOSRScene() {
previewNode = new GameNode(“Right Panel Node”);
Sphere sphere = new Sphere(30, 30, 5);
sphere.setTextureMode(Sphere.TextureMode.Original);
previewObject = new Geometry("Right Panel Body", sphere);
previewObject.setLocalTranslation(Vector3f.ZERO);
// rotate sphere 90 degrees in radian
previewObject.rotate(1.57079628f, 1.57079628f, 0);
previewNode.attachChild(previewObject);
previewLight = new DirectionalLight();
previewLight.setDirection(Vector3f.UNIT_X.negate());
previewNode.addLight(previewLight);
previewNode.updateGeometricState();
}
[/java]
The meat of it happens when there’s a selection in the scene. I’ll pass the reference to this object and depending what it is and it’s data I’ll “paint” it one way or another. Right now all I’m getting is nothing. 
I’m not sure what to try to get the sphere to render. There is no error.
@madjack said: Gripes time! :D ;)I can’t seem to get my preview to work. -.- Probably me…
Here’s what I’m doing.
In the class constructor:
[java]
createOSRScene();
rightPreview = createRightPreview();
rightPreview.hide();
[/java]Here’s the OSR’s method (tame stuff):
[java]
private void createOSRScene() {
previewNode = new GameNode(“Right Panel Node”);Sphere sphere = new Sphere(30, 30, 5); sphere.setTextureMode(Sphere.TextureMode.Original); previewObject = new Geometry("Right Panel Body", sphere); previewObject.setLocalTranslation(Vector3f.ZERO); // rotate sphere 90 degrees in radian previewObject.rotate(1.57079628f, 1.57079628f, 0); previewNode.attachChild(previewObject); previewLight = new DirectionalLight(); previewLight.setDirection(Vector3f.UNIT_X.negate()); previewNode.addLight(previewLight); previewNode.updateGeometricState(); }[/java]
The meat of it happens when there’s a selection in the scene. I’ll pass the reference to this object and depending what it is and it’s data I’ll “paint” it one way or another. Right now all I’m getting is nothing.
I’m not sure what to try to get the sphere to render. There is no error.
Are you using the OSRViewPort class? If so, can you show me the code where you initialize it?
@madjack If you are not using the OSRViewPort, then you’ll want to use the following to set the Element texture to your OSR output:
[java]
getElementMaterial().setTexture(“ColorMap”, osrBuffer.getTexture());
getElementMaterial().setColor(“Color”, ColorRGBA.White);
[/java]
Personally, I think it is easiest to just use the following:
[java]
// These first two lines are all that is required to get it to render your scene
// null can be replaced with an image path to overlay over your viewport if you need it
OSRViewPort subView = new OSRViewPort(screen, “subView”, new Vector2f(8,38), new Vector2f(198,396), new Vector4f(0,0,0,0), null);
subView.setOSRBridge(newScene, 256, 512);
// Past this, you can set up basic element behavior and camera interaction
// Background color
subView.setBackgroundColor(ColorRGBA.DarkGray);
// Allow camera rotation
subView.setUseCameraControlRotate(true);
// Allow camera zoom
subView.setUseCameraControlZoom(true);
// Setup camera behavoir
subView.setCameraDistance(2f);
subView.setCameraMinDistance(0.15f);
subView.setCameraMaxDistance(5f);
subView.setCameraHorizonalRotation(90*FastMath.DEG_TO_RAD);
subView.setCameraVerticalRotation(0);
// And basic element behavoir
subView.setIsMovable(false);
subView.setIsResizable(false);
subView.setDockW(true);
subView.setScaleEW(false);
subView.setScaleNS(false);
subView.setClippingLayer(someElement);
// etc, etc, etc…
[/java]
@t0neg0d said: Are you using the OSRViewPort class? If so, can you show me the code where you initialize it?
Whoops. Forgot to include that. -.-
Here it is.
[java]
private Panel createRightPreview() {
Vector4f borders = mainScreen.getStyle(“Window”).getVector4f(“resizeBorders”);
String pathToBGImg = “Textures/GUI/panelBottomOpen.png”;
Panel rp = new Panel(mainScreen, "RightPreview", settings.getRightPreviewScreenLocation(), new Vector2f(225f, 331f), borders, pathToBGImg);
OSRViewPort preview = new OSRViewPort(mainScreen, "Preview", Vector2f.ZERO, new Vector2f(220f,220f), Vector4f.ZERO, null);
preview.setOSRBridge(previewNode, 220, 220);
Camera panelCam = preview.getOSRBridge().getCamera();
panelCam.setFrustumPerspective(90.0f, 1f, 1f, 75f);
panelCam.setName("Right Preview Camera");
panelCam.setLocation(new Vector3f(10, 0, 0));
panelCam.lookAt(Vector3f.ZERO, Vector3f.UNIT_Y);
preview.getOSRBridge().getViewPort().setClearFlags(false, true, true);
preview.getOSRBridge().getViewPort().setEnabled(true);
Panel lower = new Panel(mainScreen, "LowerPreviewMenu", new Vector2f(7f, 232f), new Vector2f(210f, 91f));
lower.setIsResizable(false);
lower.setIsMovable(false);
rp.addChild(preview);
rp.addChild(lower);
rp.setIsResizable(false);
return rp;
}
[/java]
Also, on a different topic, is there a reason why moveable and resizable are, by default, true? I would have expected the contrary as 90% of the controls are inside another that you would want to only have the top parent moveable. Because of this you have to specify false for each and every sub-control in a screen…
It’s not really an issue, just that it’s easily forgettable to set those false and end up with control somewhere that can be moved and resized when it shouldn’t. In the end I think it’s just an issue of time spent (wasted?).
@madjack said: Also, on a different topic, is there a reason why moveable and resizable are, by default, true? I would have expected the contrary as 90% of the controls are inside another that you would want to only have the top parent moveable. Because of this you have to specify false for each and every sub-control in a screen...It’s not really an issue, just that it’s easily forgettable to set those false and end up with control somewhere that can be moved and resized when it shouldn’t. In the end I think it’s just an issue of time spent (wasted?).
By default, the Element class has both of these set to false.
The Panel class has both set to true as it was supposed to be an alternative to window. I can change this though.
The OSRViewPort may have both set to true as well… but that was unintentional and I’ll fix that if I left it that way.
I’ll also take a look through all controls and change this on any that were set that way unintentionally.
Now… about the viewport. Do me a favor while I test the code you posted. Comment out lines 6-15 in createRightPreview and tell me if you can see the scene. The OSRViewPort creates a chase cam that is looking at the center of the scene by default. Most of what you have in 6-15 should not be an issue, but setLocation and lookAt may be a problem.
Also… you shouldn’t have to call any of these:
[java]
previewNode.updateGeometricState();
preview.getOSRBridge().getViewPort().setClearFlags(false, true, true);
preview.getOSRBridge().getViewPort().setEnabled(true);
[/java]
Actually… lemme address each specifically
n.updateGeometricState - This is handled in the update loop of the control.
vp.setClearFlags - I see you’re not clearing the color buffer. Out of curiosity, are you using the past rendered frames for something? By default the control sets all to true. Should this be revisited?
vp.setEnabled - Once you call hide on the top level panel, the viewport is disabled and removed from the scene. When you show it, it is reattached and enabled again. So no real need to call this.
So, instead of setting the camera as above. Grab the camera to set the perspective and such… and the try:
[java]
preview.setUseCameraControlRotate(false); // unless you want people to be able to rotate the model
preview.setUseCameraControlZoom(false);
preview.setCameraDistance(10f);
preview.setCameraHorizonalRotation(0);
preview.setCameraVerticalRotation(0);
preview.setCameraMaxVerticalRotation(0);
[/java]
This should set up the chase cam the same way you have the default set up. If you decide to allow people to rotate the planet/object/etc and don’t want to limit the vertical rotation, remove the last line… or set it to whatever limit, etc, etc…
I haven’t had the time to test or fiddle with anything, but I wanted to let you know that the settings I used above were, for the most part, what I was using with the old way I was doing it after testing a barebone test run, which didn’t work well either. That’s why you’re seeing the wonky stuff.
I’ll repost with result when I can.
It was my fault from the start.
The OSR won’t render anything if its panel is not added to the screen. Did you know that?
Except for the SpatialObject being off center it’s working great. I can even say that, for now, there is no impact on FPS vs the other way, which was killing ~20% of it.
Finally got this to work properly and fix the alignment, but there’s one thing bugging me. The OSR is above the panel (z-order it seems) so when I click on the panel (through the OSR) to move it elsewhere on the screen, it doesn’t get propagated to the parent and thus the panel isn’t moved. Is this by design or maybe there’s something I need to toggle?
FYI, I know this is nit-picking at its best (worse?), but you definitively should use Vectorf.ZERO instead of the whole new Vectorf(0,0,0,0); …
ADD:
Also just tested this, when I drag a moveable panel the click is not consumed.