Add Path to GTK backends to unlock shapes

[DivineDominion]

Just yesterday, #123 was merged with support for WinUI, AppKit, and UIKit. Thanks @bbrk24 for the effort! 🙌

The GTK backends declare Path = Never at the moment, so no GTK path support, yet

This issue is meant to track this, to coordinate efforts in case someone wants to implement that before I get around to trying it myself :)

[stackotter]

Thanks for creating a tracking issue, good idea 👍

I’ll just add a little context for anyone tackling this issue;

@bbrk24 can probably elaborate further but I think one of the main annoyances was that ellipses are a bit tricky to render with consistent stroke width. This resource should help with that: https://cairographics.org/cookbook/ellipses/.

The other issue that I remember @bbrk24 facing was that applying transforms to specific parts of paths is a little different to the other backends. That ellipses blog seems to use an approach that would help here too. More specifically @bbrk24 said;

Actually it looks like the approach here is generally applicable! I just have to reorder it so that instead of [...path1, transform1, ...path2, transform2] it's [transform1, ...path1, transform2, ...path2]

Hope that helps!

[bbrk24]

ellipses are a bit tricky to render with consistent stroke width

I specifically implemented the Ellipse shape as a circle with a transform applied, rather than requiring the backends to support ellipses directly, for exactly this reason. And yeah just like that blog says we'll have to undo the transformation before doing anything relating to the stroke. Finally, unlike the other backends the loop over the actions array will probably have to be in the render function instead of the update function.

Another complication I ran into is that the coordinates of the path are relative to the Shape's bounds, but it looked like GTK's API for getting a reference to the drawing context gives you one for the whole window, not just the one widget.

[stackotter]

Another complication I ran into is that the coordinates of the path are relative to the Shape's bounds, but it looked like GTK's API for getting a reference to the drawing context gives you one for the whole window, not just the one widget.

Not sure whether you tested that in practice or not, but if not it could be the case that the docs were referring to a widget’s GdkWindow which I believe is per widget and corresponds to that widget’s drawing area.

[bbrk24]

Yeah I had not tested that. Good to know that GdkWindow is per-widget.