Rotate UIWidget

[eruvanos]

Enhancement request:

Allow rotation of widgets.

What would it help with?

Having animation for GUIs is the logical next step. Such animations often contain some rotation of widgets. Also playful menus sometimes rotate the buttons to present them in a game specific style.

Known issues:

• Rect does not support rotation
• Rect: In bounce checks do not support rotation
• Rotating the content of a widget messes up the required space, so layouts are not able to deal with them

First Brainstorming

UIWidgets keep non rotated rect, but the inside content_rect can be rotated. In this case it will shrink to stay within bounce of the rect (inc border and padding) Such implementation will also not interfere with the layouts.

[eruvanos]

@DragonMoffon @pushfoo any thoughts?

[pushfoo]

TL;DR: Rect is a doc issue + we're touching on larger hitbox / layout design which may need post-3.0 thought

Rect does not support rotation

Rect is an AABB. I merged @DigiDuncan's Rect PR without a thorough doc proof-reading pass because we needed the features ASAP.

I agree the current Rect could be clearer about the AABB. We could probably fit it in the first line of the docstring and after as something like this:

An Axis-Aligned Bounding Box (AABB).

Since it is axis-aligned, you will need to $WORLD_SPACE_TRANSFORM

I can work on this change in a bit. As to the larger set of concerns, I brought some of this up with the pyglet team in the past:

• It would be good to have a HasLayoutProperties annotation as a Protocol type or similar:
  1. https://github.com/pyglet/pyglet/issues/939
  2. Related Discord thread

The summary is:

• It's hard to performantly calculate width and height for layout purposes when rotations are applied
• We didn't ever come to a conclusion about how to resolve it
• I've wondered whether radius-based heuristics would be better for layout:
  1. Updating state radius = max(dist(pt, points.centroid) for pt in points)
  2. Use the GPU / C to make it faster?