I’m going to be updating a few things in the Element class to try and phase out the off the cuff design choices, and would like to hear opinions before I commit the changes:
First one is phasing out the current method of defining docking.
This is going to change to:
Element.setDocking(Docking.NW); // Or NE, SW, SE
The current way this is set is… hmmm… how should I put this… oh yeah… really f’ing lame. I will @Deprecate the current methods and modify them to call the setDocking method appropriately. So this will not impact anything you’ve done/built/etc so far.
I’d like to centralize Orientation to Element, instead of being unique to the individual controls.
The reason this is the way it is… is because originally, there was only a single control with this option… and then the list of provided controls grew, and grew, and grew… now there are more local enums with the same values than I care to admit.
This WILL effect your code, as you will have to change the reference to the Element enum. If you have a significant issue with this, please let me know now, so we can discuss other options.
I’ll be updating all List-based controls with code to auto-highlight the last added list item, or the list item that assumes the index on removal (or the previous index if it was the last in the list), or reset if the list is empty or cleared. This update is mainly to polish SelectList.
Menu will be getting a scrollToSelected method, which will effect SelectList & any Menu resized to enable scrolling. I’ll likely rework ComboBox to leverage this.
I’ll be adding a new control SelectListEditor… at the moment it provides user-driven sorting for single select SelectLists. I’ll update this to support the multi-select option (hopefully sooner than later). It will also contain optional edit/remove buttons, if you have a need for them.
I’m going to finally fix the offset for the Slider control’s thumb. I could have sworn I fixed this already, but learned recently that it still sucks. Sorry
#2 is completed and committed. Silly me, I didn’t realize that the Orientation can be referenced via the control name and will still inherit from Element, as all controls eventually extend Element.
This has no impact on your existing code what so ever.
Some other fixes that are getting pushed out along with these:
setEffectZOrder only needs to be set on the absolute parent now. If a child is clicked the check is run against the absolute parent, as this is the element that is effected.
Text now fades with the fadeIn and fadeOut effects.
Another note concerning text… I am going to start experimenting with pushing the rotation matrix out to the shader, so clipping bounds can be rotated as well. There is no guarantee that this will work, but thought I would mention the effort. IF it DOES work out, you’ll be able to do some really cool stuff with effects when text is involved. At the moment, due to clipping, this can limit what you would want to do.
Patches for alignment issues with scrollable areas (such as menu, select list, etc) from @rockfire were applied.
Per request from @madjack, DragElement now has bindToDroppable(Element el) method
Added a (possibly temporary) fix for cursor hotspots.
Added resize cursors, if you are not using custom cursors… I suggest trying it out)
TextElement now has support for <u>, <i> <br> and <p> plus in-line alignment changes.
Still haven’t gotten hyperlinking ported from test yet, as it is not an easy port… Support for AnimElement geometry ray casting needs to be added to Screen. It’s the next thing on the list of TODO’s.
Could use some help from a Mac User if at all possible. =)
I recently committed an update to the shaders used for the library in hopes of resolving a performance issue on Mac when effects are run. This has a slight benefit for Windows & I’m assuming will have the same benefit for Linux. Would be ideal if it helped with Android as well, but I haven’t tested this yes.
The changes should have no negative effect, however, if anyone notices something that looks wrong, performs worse or just is not working properly with the way elements are rendered, please let me know.
So i was wondering why my text in a scrollArea wasn’t clippt if it’s outside the scrollarea. After looking into chatbox code i found out that
[java]scrollArea.setClippingLayer(scrollArea);[/java] fixed this. It would be great if this command is postet onto the tutorial page and find his way into documentation.
@b00n said:
So i was wondering why my text in a scrollArea wasn't clippt if it's outside the scrollarea. After looking into chatbox code i found out that
[java]scrollArea.setClippingLayer(scrollArea);[/java] fixed this. It would be great if this command is postet onto the tutorial page and find his way into documentation.
After reading my post again. I think that i was a little unclear. What i meant is that if i use the scrollArea as described on the tutorial page the text and addScrollableChild() did not work correctly. After reading how the Chatbox is clipping correctly, i found out that doing scrollArea.setClippingLayer(scrollArea);, quite after new ScrollArea(...); clipps it correctly.
Or do you want me to test it again without this extra command?
Sorry… following now. You’re using this with a ScrollArea. Are you using ScrollArea or ScrollAreaAdapter? The first was really built for internal use and is not overly user friendly
Hmm, i’ve started to get null pointer exceptions with the newest updates?
Problem is with super(screen…
public class ActionButton extends Button {
GUIListener gl;
public ActionButton(Screen screen, String UID, int x, int y, String text) {
super(screen, UID, new Vector2f(x, y));
this.setText(text);
}</blockquote>
[java]startExploreMode = new ActionButton(screen, “exploremode”, 100, 100, “Explore Mode”);[/java]
I’ve checked and screen definitely isn’t null.
I think with the new update you doenst need the screen class for the button.
Buttons have now the ElementManager screen.
Example:
[java]
public class ButtonBase extends ButtonAdapter {
public ButtonBase(ElementManager screen, Vector2f position) {
super(screen, position);
init();
}
@Snowsun92 said:
I think with the new update you doenst need the screen class for the button.
Buttons have now the ElementManager screen.
Example:
[java]
public class ButtonBase extends ButtonAdapter {
public ButtonBase(ElementManager screen, Vector2f position) {
super(screen, position);
init();
}
}
[/java]
Screen is a sub-class of ElementManager, as is SubScreen (for embedding UI components into your 3D scene). This change was added about 6-8 months ago and shouldn’t effect how things work.
If you’re seeing a problem with this, do let me know.
@Snowsun92 said:
I think with the new update you doenst need the screen class for the button.
Buttons have now the ElementManager screen.
Example:
[java]
public class ButtonBase extends ButtonAdapter {
public ButtonBase(ElementManager screen, Vector2f position) {
super(screen, position);
init();
}
}
[/java]
Hmm, where did you find that? Can’t find any infos in javadocs.