You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If BusyBar is added directly to a Stage or a parent that does not clip it by default (like Table or Container), it will be drawn over other widgets and actually take much more space than its width setting allows it to. The widget currently works as expected only when paired with a Window.
When BusyBar width equals zero, it will not move at all, but its image will still be drawn in its fullest (again - taking much more space than 0). The lack of movement might be expected, but I still think the BusyBar drawable should be clipped to its current width.
The widget itself could also use some additional properties like speed modifier and moving direction (both possibly accessible through its style?).
The text was updated successfully, but these errors were encountered:
The widget itself could also use some additional properties like speed modifier and moving direction (both possibly accessible through its style?).
Speed modifier can be achieved by overriding getSegmentDeltaX(), it depends on width so it's not hardcoded into skin. Do we really need busy bar moving in other direction?
I can confirm that the busy bar is correctly rendered in the latest snapshot.
To be honest, it would be nice to be able to modify speed and movement direction through widget properties, but it's such a niche actor that it's not really necessary.
If
BusyBar
is added directly to aStage
or a parent that does not clip it by default (likeTable
orContainer
), it will be drawn over other widgets and actually take much more space than itswidth
setting allows it to. The widget currently works as expected only when paired with aWindow
.When
BusyBar
width equals zero, it will not move at all, but its image will still be drawn in its fullest (again - taking much more space than0
). The lack of movement might be expected, but I still think theBusyBar
drawable should be clipped to its current width.The widget itself could also use some additional properties like speed modifier and moving direction (both possibly accessible through its style?).
The text was updated successfully, but these errors were encountered: