Slick Forums

Is there a best practice for moving a TWL widget around on the screen?

For example I want a label following the mouse. I read in the documentation that Widget.setPosition() should only be called in layout() of parent. Isn't this an expensive method to call on each frame?

Furthermore I want some inventory box move out of the screen and come back when needed with the same mechanism.
How can I do this best?

Thx!

There are a few special cases - I assume the container/parent of that label or the inventory box is your own widget and covers the whole screen. In this case you can change the position directly (eg from the handleEvent method) as long as you make sure that the container and the widgets won't work against each other. It probably involves some debugging to get it working correctly - esp if you also support resizing of your container/game window.

Take a look at DesktopArea and ResizableFrame.

_________________
TWL - The Themable Widget Library

What does "won't work each other" mean exactly?

The parent widget is mine, right. Covers the whole screen... don't know... I use a plain Widget as root widget for the GUI object and I haven't set a widget size. Anyway my client widgets are visible. I only don't know how to move them...

The movable widgets don't need to resize, hence I want try to put everything into an ScrollPane... Do I need a DesktopArea and ResizableFrame then?

I wrote "don't work against each other" - eg the parent setting a size on the label, then the label resizes itself, parent causes re-layout etc...

The root widget always covers the whole size of the GUI instance which by default is the whole view port.

And the DesktopArea and ResizableFrame reference was because these 2 classes already do something similar. The ResizableFrame responds to mouse events to move and resize itself, while the DesktopArea ensures that no widget gets moved outside but otherwise don't affect the position&size of it's children.

_________________
TWL - The Themable Widget Library

Thanks for the answers!
Sorry, I indeed read it correctly, but missed typing one word...

Ok, I think I understand now. Moving on a plain Widget could work ok, because there is no "layouting code" in the Widget, as it would be in BoxLayout or similar, right?

I think DesktopArea/ResizableFrame does not fit my needs, because I don't want to let the user change size and position of the widgets, I only do want adjust this from code...

Another (quite theoretical) question: what kind of impact does the size of a (plain) Widget have on it's children? I've encountered no difference at all, neither visibility, nor alignment or something?
As far as my understanding goes, the size of some Widget only has meaning to itself (rendering etc.)... and of course e. g. a BorderLayout's size determines the size and position of its children... (because layout() is overriden).
I ask this because you mentioned the size of the root widget, which automatically has size of the viewport as you explained. But if it would be smaller (hypothetically)... Or, to be more realistic, let's say we add another (plain) Widget to the root widget and then a Button as child of this second Widget. If the widget would be very small, the Button is visible anyways, right?

It matters for event routing and when clipping is enabled also for rendering.

_________________
TWL - The Themable Widget Library