Slick Forums

Hi Matthias/everyone,

I'd like some advice on the best way to get the sizing for a Widget inside a DialogLayout. I've got a way that works, but I'm hesitating because it's seems like I'm taking advantage of the ways certain things work internally in TWL, and if for any reason that changes, my code might not work as expected anymore.

Here's the situation so far: I have a Widget that I am using like a drawing canvas, just a blank space where I draw my game elements. The size of this space is dependent on the layout of a group of Widgets within its parent, essentially it grabs the biggest space available to it. At first I made this Widget a sub class of Container and it worked perfectly because I overrode getPreferred..() and requested a space that was as big as its parent, as a result DialogLayout trimmed it down... the getMinWidth/Height() methods both returned 0 by default from Container.

I needed to introduce some drag and drop elements within my game elements, and because Container doesn't get all the mouse events (such as dragging events), I changed the super class of the drawing canvas to Button. So now I'm drawing onto the front of a big button essentially, and everything works great drag and drop wise, but the layout is different. My assumption is that Button differs to Container in that Button takes getMinWidth/Height() from getPreferred..(). So I override getMinWidth/Height() to return 0 instead, and now it lays out perfectly again.

My main question is, is it ok that I've done it this way, or should I be doing it another way? Perhaps even there's a way to query the DialogLayout to the dimensions that are available for a Widget or Group item? The assumptions I'm making about TWL layouts for this essentially are, if I return a big dimension from getPreferred and a small one from getMin then DialogLayout will first honour getMin and then return the max it can to honour getPreffered. This works for me, but can I depend on this assumption?

Thanks for any advice/help!
tomas

In case my description is confusing, here's the details of what each type of Widget returns from sizing methods:

Hello,

Container only makes sense to use when you want one child widget using the full size. Otherwise you should subclass Widget.

Regarding mouse events - did you read the javadoc of handleEvent() ? You need to handle all mouse enter/exit and mouse movement events for dragging to work. This is easily done by doing inside your handleEvent method.

As for the min/preferred/max size question. DialogLayout tries to give each widget it's minimum size, but not more then max size. The preferred size is only used to determine the optimum size of the DialogLayout itself (doesn't matter if DialogLayout gets it's sized forced from it's parent - eg a ResizableFrame) and to determine how to distribute extra space.

Max size is special - if it is 0 it means that this widget doesn't want to grow.

Let's assume you have 800px of available space and the following widgets:
A min=100,pref=100,max=0
B min=0,pref=0,max=32767
C min=50,pref=50,max=0
then A will always be 100 wide, C will also always be 50 wide. The remaining space (650px - 2x default gap) is then given to B.

If you have more then one element with max > 0 then the remaining space (after subtracting all min sizes and gaps) is distributed based on their preferred size (until it reaches the max size).

_________________
TWL - The Themable Widget Library

Yes, one child full size was exactly why I chose Container. Subclassing Button works perfectly though, it must've been a slight accident, because I only now fully understand what was meant in the handleEvent() javadoc... I was returning the value from the super.handleEvent() even after I used it, so true was being returned by default... not because I understood what I was doing. But now I get it, so thanks for that!

Thanks also for detail on the sizing. Now I understand that by setting the preferred size to a large value it is causing DialogLayout to grab as much space as it can to satisfy it. It's a great tip to set max size to 0 for no growth too!

Is there a good way to debug DialogLayout by the way? I seem to have a mental block on how to get it to do what I want... and spent hours on simple layouts trying things to get it right. I don't know why my brain struggles with it, but if there's a way to see what it's doing with my groups, either visually or textual, it would really help me!

thanks again

If you have a good idea how to visualize that then I could try to implement it. The problem is that horizontal layout is totally independent from vertical and this makes drawing things hard.

_________________
TWL - The Themable Widget Library

Yes I appreciate it would be quite a challenge, since groups can be nested. Would it be possible to assign an arbitrary colour to every group in the layout (both horizontal and vertical) and simply outline the group... purely in a "debug mode" of some kind, perhaps theme set? Perhaps a nested label system like v1, v2, v3.1.2, h1, h2 etc in the appropriate colour too alongside the outline.

If that was possible, even better could be to also give gaps a fill or outline, to show where they are influencing things.

I think some visual representation of the groups would be way easier to interpret than a textual one.

The problem is that a horizontal group has no vertical information. So you could only draw vertical lines for the horizontal groups.

_________________
TWL - The Themable Widget Library

Oh, I see.

I imagined because it seems like there's an expanding grid being created with straight lines and grids within grids. So lots of nested rectangles, which it seems like you could plot accurately. Obviously, that's not the way you actually construct it.