I am trying to create resize borders to my dialogs (yes, rectangular boxes with text on it as usual :)).
I am using buttons for that, the center element in the border layout will go everything else.
The problem is north and south buttons that will not shrink to like 3 dots in height, east and west will be 1 dot width if I put no text on it.
So, before trying to set the preferred size, I get that value to use as minimum constraints (x,y,z).
Force scaling the button is not an option, I tested.
Try setting the font size really small. I guess since you are using buttons that the text has some height constraints when determining preferred size.
I think there probably are better ways to do this though your approach is pretty clever.
Another approach would be to build a ResizablePanel type class that forces a particular background component that is your resize borders. The GUI content could then be a child panel. You could then just add a mouse or cursor listener to yourself to detect when dragging on the borders is happening.
The RollupPanel might be a good example of a GUI element that manages a child.
I recommend using a CursorListener for mouse clicking because it will give you the actual collision information… which can be useful for verifying that your own background was what was clicked and where it was clicked.
Else your current approach is probably the easiest if you can get your sizing stuff worked out.
Is it possible to configure the identification of specific elements so we could set that on the style? or the above direct color setup is the expected, being the style really the generic and not the specific?
PS.: before modifying the button bkg color I backup it with setUserData() on the very spatial (quite cool this thing btw), so I can restore it later (in case of mouse hovering bkg highlight).
If I understand the question correctly, this is what ElementId objects are for. They identify the “class” of object to the styling system. (For example, by default Button has an ElementId(“button”))
You can read more details about styling here:
By the way, I believe this code is being redundant:
You’ve asked for the background component then asked for the gui control that contains it… then asked for that control’s background component. Which should be the gcBkg you already grabbed.
I am using this to let me freely modify the dialog size without crashes:
pnl.setPreferredSize(newsize);
if(pnl is attached to GuiNode){
try{
pnl.getControl(GuiControl.class).update(1f/30f); //use real fps?
// pnl.updateLogicalState(1f/30f);
}catch(IllegalArgumentException ex){
pnl.setPreferredSize(backup); //restore the backup
}
}
So basically, if the user tries any invalid size, it will be restored to a safe one.
If I didnt check for the GuiNode it would have bad side effects like some style initializations would fail and listeners would get deaf.
Basically, I would like to let lemur try the new size and throw any problems it finds so I can restore in case of failure. I wonder if it may cause me trouble later or if this trick is robust enough? because I understand the update is not happenning when it should.
Mostly, the Lemur GUI elements are already pretty aware of if they are attached or not. Thought there might have been an easy way to answer that question.
Curious, in what case will you be getting drag events when it’s not in a situation where a drag could/should be handled?
I actually configure everything before attaching them to the GuiNode, including the initialization preferred size, so it may happen while it is not attached yet.
And, another thing I do is, to hide the dialog (top Spatial directly attached to GuiNode) I just detach it from the GuiNode, and some configurations may happen while it is not attached too.
May be I should queue and check before apply changes to everything… may solve some problems I face from time to time, I think I work better with lazy initializations and validated/postponed apply of configurations :).
I think it is because of some delayed visual effects I am using…
but this made things get stable (not crash), despite the dialog looks bad and incomplete whenever an impossible layout happens (like 1x1 lol) it is not really a problem now:
I think I will even override all dialog contents with a simple label “impossible layout”, will make things clear to users so they can grow it back (happened only when shrinking)
basically, the resizable background border (BkgResBor), after the contents panel are set above it, even if I set the contents preferred size to -= border*2 (in X and Y, where border=3), the contents will expand and hide the BkgResBor, any idea what to do?
should I set some kind of invisible borders (?) so that BkgResBor is raycast hittable?
but then, wouldnt the very borders be enough instead of that BkgResBor? or it still would have any advantage?
You are saying that the outer panel does not have any “space” around the contents that it contains?
You either need to give your outer panel a border that has a margin or you need to give your inner panel insets. The right idea is probably to give the outer panel a border component that has its margins set properly to be whatever the border wants to display.
btw, it is almost working, I can already drag to resize, but only corners right and bottom work partially.
also, if I drag too fast in a direction outside the panel it will stop dragging, but I think there is some methods there to deal with that, I will try it later
it is minimalistically working! as we still have to move the mouse slowly or it will lose the dragging hook when moving towards outside the ResizablePanel…
Also, I believe you may consider the code a bit messy: missing constructors I didnt use on the test, not your coding style, may be a few more issues…
would you be interested in absorbing this class?
or I just put it into my other project?
later on, you can grab it anytime you want anyway,
despite I believe you may even implement the “complex” (to me) part, in a completely different way
Personally, I would not use drag and drop stuff for a resize border. I’d just add a listener, set consumed on the event, if the mouse goes outside of the border then increase the size in that direction.
DragAndDropControl is meant for something completely different.