Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BusyBar is not clipped if not in a window parent #222

Closed
czyzby opened this issue Oct 8, 2016 · 3 comments
Closed

BusyBar is not clipped if not in a window parent #222

czyzby opened this issue Oct 8, 2016 · 3 comments
Labels

Comments

@czyzby
Copy link
Collaborator

czyzby commented Oct 8, 2016

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?).

busybar

@kotcrab
Copy link
Owner

kotcrab commented Oct 8, 2016

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?

@kotcrab
Copy link
Owner

kotcrab commented Oct 8, 2016

@czyzby please confirm the clipping is working correctly.

Forgot to mention issue in commit 0d5ac36.

@czyzby
Copy link
Collaborator Author

czyzby commented Oct 9, 2016

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.

@czyzby czyzby closed this as completed Oct 9, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants