@TsrKanal said:
Hmm. A list that can also include bitmaps as rows. I want to create them manually with a imagepainter. They should also be dragable to
another list or to a slot - like an actionbar, or similar. And then some kind of slot container - I think this can be similar to what you have in mind
with the "Configurable Containers". Some table control for showing statistics would also be nice.
Also, forgot to answer your question about themes.
Yes… I will definitely be adding a plugin with themes, as soon as the library hits a solid Alpha.
Got a request for something that could help a few people (like me)…
Being able to Scale an entire screen of elements, so I can design a layout for a single screen size (say 1920x1080) then just tell the screen to set scale to 0.75 for a different screen size (say 1440x900) .
This way I can design a single layout for each of the possible formats (4:3, 16:9, 16:10, 3:2), and be able to accommodate any resolution with minimal effort.
@Dardzull said:
Got a request for something that could help a few people (like me)..
Being able to Scale an entire screen of elements, so I can design a layout for a single screen size (say 1920x1080) then just tell the screen to set scale to 0.75 for a different screen size (say 1440x900) .
This way I can design a single layout for each of the possible formats (4:3, 16:9, 16:10, 3:2), and be able to accommodate any resolution with minimal effort.
In theory, this is what percentage position and size is for. If you specify position 0.4, 0.45 and size 0.2 and 0.1, element will be positioned in middle of the screen with 20% width and 10% height. Detection logic is simple - if it is below 1, then it is percentage (not sure about _exactly_ one).
@Dardzull said:
Got a request for something that could help a few people (like me)..
Being able to Scale an entire screen of elements, so I can design a layout for a single screen size (say 1920x1080) then just tell the screen to set scale to 0.75 for a different screen size (say 1440x900) .
This way I can design a single layout for each of the possible formats (4:3, 16:9, 16:10, 3:2), and be able to accommodate any resolution with minimal effort.
XD
I sooo agree with you here. A few questions concerning this… how recursive should this scaling be? Should it alter top level (screen component size/placement only? Or rescale everything? At a certain point this gets confusing, as ComboBoxes/SelectBoxes might not display the content in the way you originally had in mind. If I can get some input from you and whoever else might have some insight into how to best handle this, I should be able to get it implemented fairly quickly.
@abies said:
In theory, this is what percentage position and size is for. If you specify position 0.4, 0.45 and size 0.2 and 0.1, element will be positioned in middle of the screen with 20% width and 10% height. Detection logic is simple - if it is below 1, then it is percentage (not sure about _exactly_ one).
This was an idea that never fleshed out completely… there were problems with relative positioning prior to adding components to their parent elements. I tried to have elements reposition themselves after the fact, but the translation never quite worked due to the Y coord flipping after the initialization. I’m sure it is possible… and hopefully, I’ll figure it out eventually… however, thus far… no luck.
Relative positioning is possible with the new XML layouts which I committed today (There is some basic info on how to use them on the Wiki)
Personally, I use the following type of thing for relative positioning
[java]
new Vector2f(parentEl.getWidth().35f, parentEl.getHeight().55f);
[/java]
knowing what the parent element will be once everything is added to it’s soon-to-be parent. And after the elements are attached to their parents/screen, resizing the using the above method is straight forward. So aside from questions about how people see this working, it will be a quick addition.
Side Note: Relative positioning is completely possible using builders (or a small implementation of a fluent API for constructors) because it gives you the chance to fact-find prior to initializing the component. This was one of the primary reasons I liked the suggestion.
For me relative positioning was needed for top-level components. I ended up manually multiplying whatever is needed with screen.getWidth and screen.getHeight.
@abies said:
For me relative positioning was needed for top-level components. I ended up manually multiplying whatever is needed with screen.getWidth and screen.getHeight.
There is also the controlResizeHook() method to allow you to decide what will scale and what won’t… so maybe just a top level component approach for now and see if it suffices for people. I’d hate to force scaling on everything only to find out it destroys people layouts in short order.
In theory, I was thinking of a top down approach by possibly using the Screen (like screen.setScale() ) to do the over all scaling (similar to scaling a Spatial, Node, etc.). That way as long as the layout is within the same format (4:3, 16:9, etc) everything should function the same. And to rescale, one would just have to clean everything out, rebuild the GUI, then set the scale size as needed.
I realize if someone was to put a 1px border around something at a resolution of 1920x1080 its not going to work at 720x480, but knowing this a person could adjust the layout to compensate for this – at least vs having to design a layout for each possible resolution, limiting to specific ones, or doing hard coded calculations (with possible special circumstances) .
@Dardzull said:
@t0neg0d
I realize if someone was to put a 1px border around something at a resolution of 1920x1080 its not going to work at 720x480, but knowing this a person could adjust the layout to compensate for this -- at least vs having to design a layout for each possible resolution, limiting to specific ones, or doing hard coded calculations (with possible special circumstances) .
Actually, this would not be a problem as long as the resizeBorders of the element are defined for the control (all have default settings) The 1 pixel border would remain constant… everything else would scale.
@Dardzull said:
Being able to Scale an entire screen of elements, so I can design a layout for a single screen size (say 1920x1080) then just tell the screen to set scale to 0.75 for a different screen size (say 1440x900) .
This way I can design a single layout for each of the possible formats (4:3, 16:9, 16:10, 3:2), and be able to accommodate any resolution with minimal effort.
How about modifying the camera parameters?
That should automatically scale everything inside the view: GUI, scenegraph, whatever, and with minimal effort.
Works ok, but it would be great if setMsg(…) was overridden (from AlertBox). Also it would be nice to have those changes:
1 - Undecorated Alert/DialogBox.
2 - Text alignment of the Msg.
#1 Because it really jars from the other “windows” I use. They don’t use that bar on top and using it at this point, it looks more like a forgotten old element. #2 Because it’s possible?
These missing are probably just an oversight though.
EDIT:
While I’m thinking about it, there should be some kind of default size defined for certain controls, ie: Dialog/AlertBox size shouldn’t be smaller than 250 x 140 more or less. Less than that and it starts looking really weird; scroll bars popping up, etc. 140 pixels high reflects default font, the bar on top and 1 line of text.
@madjack said:
Just made an attempt to use DialogBox.
Works ok, but it would be great if setMsg(…) was overridden (from AlertBox). Also it would be nice to have those changes:
1 - Undecorated Alert/DialogBox.
2 - Text alignment of the Msg.
#1 Because it really jars from the other “windows” I use. They don’t use that bar on top and using it at this point, it looks more like a forgotten old element. #2 Because it’s possible?
These missing are probably just an oversight though.
EDIT:
While I’m thinking about it, there should be some kind of default size defined for certain controls, ie: Dialog/AlertBox size shouldn’t be smaller than 250 x 140 more or less. Less than that and it starts looking really weird; scroll bars popping up, etc. 140 pixels high reflects default font, the bar on top and 1 line of text.
I’m going to be making an effort to add getters for all sub-elements of controls so you can modify each elements visuals as you see fit. In the case of controls that that leverage their super class’ Style… this is sorta critical =)
This should encompass any visual attribute (text or graphic)
EDIT: There should be a way of setting the minimum size of any control. Let me double-check that…
EDIT 2: This brings up another issue that I have been working to resolve for a while with no luck (this one hurts my head). Applying minimum dimensions to child elements and having their scaling work correctly. There are soooooo many factors involved between siblings that I just haven’t found a solution that works in all scenarios (you’ll notice a secondary resize method in the Element class that is commented out… this is me playing around with just that)
EDIT 2: This brings up another issue that I have been working to resolve for a while with no luck (this one hurts my head). Applying minimum dimensions to child elements and having their scaling work correctly. There are soooooo many factors involved between siblings that I just haven’t found a solution that works in all scenarios (you’ll notice a secondary resize method in the Element class that is commented out… this is me playing around with just that)
Aye. No doubt it’s headache’y. But I was more commenting on predefined controls. For example sliders. They shouldn’t be smaller x pixels wide by y pixels high. Same with Dialogs as anything smaller is just giving wonky, graphically wrong and buggy-looking results.
@madjack said:
Aye. No doubt it's headache'y. But I was more commenting on predefined controls. For example sliders. They shouldn't be smaller x pixels wide by y pixels high. Same with Dialogs as anything smaller is just giving wonky, graphically wrong and buggy-looking results.
Hopefully once I get the updated resize method working the way I want it to, this should not be a problem anymore. All controls have a minDimensions associated with them… they just don’t work properly with nested controls atm.
public void element.setIsVisible(boolean newState);
Why you might ask yourself? Because it’s really handy with stuff like this:
[java]
public void doWeDoSomethingHere(boolean state) {
// do whatever
screen.getElementById(“mapButtonsMenu”).setVisible(state);
// no need to check if it’s visible or not, just set it and be done.
}
[/java]
public void element.setIsVisible(boolean newState);
Why you might ask yourself? Because it’s really handy with stuff like this:
[java]
public void doWeDoSomethingHere(boolean state) {
// do whatever
screen.getElementById(“mapButtonsMenu”).setVisible(state);
// no need to check if it’s visible or not, just set it and be done.
}
[/java]
Pretty please?
What’s the difference with this one? I can get this in there now… just need to know what it does that is different than the current.
@madjack said:
There isn't a setIsVisible or anything. It's just hide() or show(). Unless you added something like that that I didn't notice?
Actually, There is… but it uses clipping instead of actually removing the elements from the scene. Either way, I need to update this, because I think that the current show/hide method using clipping + attach/remove which is overkill and causes previous state visibility issues with child elements.
Let me see about re-purposing the existing setVisible to function the way it should. I may have made these private to keep people from using them mistakenly. Either way, your request will be added. Along with a setVisible() no parameter call that will use !visible to toggle for you.
