guile-cairo support

[spk121]

Add an example of how to use guile-cairo to draw to a GtkDrawingArea in its draw callback.
Add helper functions for guile-cairo support if needed.

[LordYuuma]

IIRC Cairo comes with a Typelib ("cairo" "1.0"), so wouldn't it be easier to load it through Guile-GI and do the normal stuff? Perhaps I'm overlooking something, but to me it would appear a porting guide is more appropriate.

[spk121]

It appears that the gir and typelib for Cairo aren't actually provided by cairo, but rather by gobject, and that they are just the minimum information to cover those cairo types used by Gdk. It doesn't seem to contain any Cairo procedures other than image_surface_create

I built cairo from source to verify, and it doesn't seem create a typelib or a gir.

There are various discussions online about providing a real typelib for cairo, but, they don't seem to have a definitive resolution.

[LordYuuma]

I see. In the meantime, I had a look at guile-cairo and it appears they use smobs to store pointers to the objects themselves. Perhaps we could provide an operation (fiddle proc obj), which applies proc on the pointer of the object. One would still have to define proc however. For that, we'd have to dig up guile-cairo's native library via Guile's FFI. Would that be acceptable?

[spk121]

No need to code right away. I want to take a look at how others have done Cairo and what guile-cairo thinks its future is.

[LordYuuma]

It appears guile-cairo was pretty dead until recently. I think pygobject goes a similar route as to what you're proposing in that they use a separate binding library for cairo. Not sure about other libraries.

[spk121]

That minimal cairo information in that cairo-1.0.typelib is for libcairo-gobject.so
https://gitlab.freedesktop.org/cairo/cairo/-/tree/master/util%2Fcairo-gobject
That is a thin library that makes GBoxed GType for cairo types with copy and free methods. Loading up the cairo-1.0.typelib creates the types.

Everything on the guile-gi side of things is passing sub-types to G_TYPE_BOXED, which end up unpacked in scm_to_c_boxed() via gig_type_peek_object()

I'm seeing a thin, a fat, and a hard way forward.

• thin: convince guile-cairo to make its scm_t_bits smob typetags public and add procedures that return pointers from its smob types. This would allow guile-gi to write a utility library to convert smob types to guile-gi types and vice versa. Least code, but, most confusing for the user.
• fat: re-write guile-cairo's types altogether, replacing smobs with guile-gi classes. Add a dependency on cairo-gobject so cairo GTypes can be made. Possibly pull guile-cairo source into the guile-gi tree to accomplish this.
• hard: make a typelib for cairo

And of those, I think I like fat, because it would be least troublesome for the user.

One complication is that since libcairo-gobject.so uses g_boxed_type_register_static to create the GTypes, one has to ensure that an executable only calls those functions once.

[LordYuuma]

I personally like hard the most, as it will put an end not only to our problem but to that of any other language with a working GI implementation. On the other hand, hard is also somewhat outside of our scope.
That aside, I disagree with your verdict about thin. It is not only the easiest to implement, but also the best supported by documentation – as guile-cairo has dedicated documentation while we refer to a somewhat annotated version of the C documentation, which easily breaks in isolation due to references to the rest of the C documentation. Furthermore, it will always remain easy to port existing guile-cairo code. By maintaining our own fork, we will at one point inevitably introduce features that they don't have and vice versa, leading to more confusion than before. As much as I don't like having to clean up my variables manually, within this context it's a price I'm willing to pay.

I so far implemented a mapping from our types to theirs. This should suffice for most uses, since Gtk maintains its own Cairo contexts, which will always be of the cairo typelib variant. Perhaps it could be made stronger through type-checking, but I honestly don't know whether I care enough and whether people will find it a problem to infer the correct type on their own and choose the right function for their purpose.

[spk121]

On the point of forks diverging, I think guile-cairo -- which had one functionality patch in 2020, and then the previous functionality patch in 2014 -- is not a whirlwind of activity.

[LordYuuma]

Point taken, perhaps I was overly dramatic on that one. I stil feel as though linking a library-specific solution directly goes somewhat against our goal of generality. Perhaps something à la #32 would be nice to develop an libguile-gi-cairo outside of our tree.

[spk121]

Talking to guile-cairo folks about using foreign objects instead of SMOBs, which would let us do the conversion using GOOPS functionality

[spk121]

I did bring up the foreign objects to guile-cairo once or twice, but, without any resolution.
I have used this guile-cairo work in a test app, and it seems to work well enough.