Add the ability to rotate items and their children

[tronical]

Update: #1481 (comment)

---

For certain types of UIs - like for example a compass - we need the ability to rotate an item and its children. #1478 revives some old code to bring back this feature as:

`rotation-angle`
`rotation-origin-x`
`rotation-origin-y`

properties on any items, resulting in an injected hidden Rotate element that applies the rotation when rendering.

Commit 7b50e38 implements the rotation also for the Skia backend.

There are a few things left before this issue can be considered complete:

• The API needs to be reviewed / discussed. Is this the correct approach, or do we need a more general "transform" API? Could we start with this and generalise later?
• Input events need to be subjected to the rotation as well.
• These properties need to be documented, preferably with an inline example.

[ogoffart]

Regarding the origin, i wonder if it would not be better to have, instead of

rotation-origin-x: width / 2;
rotation-origin-y: height / 2;

Maybe something like one property of type point:

rotation-origin: { x: width / 2, y: height / 2 };

One day if we add tuple to the langage, we could even shorten it to rotation-origin: (width / 2, height / 2);
But what we can already do is use the % as rotation-origin: { x: 50%, y: 50% }; although that would then be easier with two different properties.

Edit: Should the default not be (50%,50%) anyway?

[ogoffart]

Maybe it is also better in the first release to limit rotation to Image elements, that do not have any children.

This would solve the issue with translating input events.
And this would make it easier for the implementation in the software renderer if only images can be rotated.
(Rotating Rectangle (possibily with border), Clip and Text is each some work to do)

Image rotation is the primary use case for this feature anyway.

[tronical]

Regarding the origin, i wonder if it would not be better to have, instead of

rotation-origin-x: width / 2;
rotation-origin-y: height / 2;

Maybe something like one property of type point:

rotation-origin: { x: width / 2, y: height / 2 };

Yes. I think this would apply to quite a few places where we have foo-bar-baz that would be better written as

foo-bar: { baz: 42; blub: 100; }

I've been thinking that this is something that we could perhaps implement generically in the compiler. We maintain to have individual rotation-origin-x and rotation-origin-y properties in the implementation, but we allow for the syntactic sugar to write rotation-origin: { x: ...; y: ... }.

If for some reason that's a little too "magic" then we could at least annotate these kind of property groups where we allow that in builtins.slint, for example for all the font-XXX properties.

One day if we add tuple to the langage, we could even shorten it to rotation-origin: (width / 2, height / 2); But what we can already do is use the % as rotation-origin: { x: 50%, y: 50% }; although that would then be easier with two different properties.

Edit: Should the default not be (50%,50%) anyway?

Yes!!

[tronical]

Maybe it is also better in the first release to limit rotation to Image elements, that do not have any children.

This would solve the issue with translating input events. And this would make it easier for the implementation in the software renderer if only images can be rotated. (Rotating Rectangle (possibily with border), Clip and Text is each some work to do)

Image rotation is the primary use case for this feature anyway.

For the record, that's fine with me :)