Re: [cairo] gobject boxed types

[Behdad Esfahbod <behdad behdad org>]

Colin Walters wrote:

> Here is a patch, should apply to the latest git.

I also like to see gobject enum types for cairo.

Also, should the type names be CairoContext-like or simply cairo_t?  If this
is going to be used by introspection stuff, CairoContext sounds correct.

Vladimir Vukicevic wrote:

> Hmm.. my biggest problem with this is that it's essentially putting a
> language binding into Cairo -- a binding to the glib type system.  No
> other language binding is present inside Cairo.  However, I do
> understand that there are a lot of glib-using projects for which this
> would be beneficial.  Why not put this in an entirely separate (and
> simple) cairo-glib library?  That gives glib-using projects something
> clear to link with, and it avoids the dependency problems that Luiz
> and others have mentioned.

Another pro argument here is that glib bindings like the one proposed are
meta-bindings, enabling automatic binding of cairo types to various languages.

As it stands [1], the proposed cairo-glib feature/library may also include
typelib data needed for glib introspection framework to automatically bind
cairo to supporting languages.  That saves quite some work of writing manual
bindings for cairo which is the case now.

[1] http://live.gnome.org/GObjectIntrospection/CairoProblem

Colin Walters wrote:

> Right; we can do that, the reason I wanted to try this first though is
> because the cairo-glib library would right now be entirely composed of
> six 4 line functions to register types.

It will quickly grow into two digit numbers, but I expect it to stay very low
at that.

> Actually I just had a random thought - what about putting this code
> into pangocairo?  All of Gtk+, GooCanvas, HippoCanvas and Clutter
> depend on Pango, and Pango depends on both cairo and gobject.  It's a
> bit of an odd fit but the dependency graph would remain unchanged.

I had thought about that before [2].  I religiously hate that solution.  So
that's not gonna happen :).

[2] http://bugzilla.gnome.org/show_bug.cgi?id=502920

Havoc Pennington wrote:

> cairo-glib seems a bit like shooting a squirrel with a bazooka, in
> terms of adding another tarball someone has to release and adding more
> overhead to symbol lookups in all apps.

libcairo-glib.so can be installed from the cairo tarball.  Separate library
doesn't mean separate tarball.  I'm in favor of this solution right now.
Remains a penalty of one dirty page per process of course.

> Or, here is the outrageous hack idea of the day: have a library that
> consists only of get_type functions for *all* non-glib-dependent libs,
> and it does dlopen(NULL) to grab the copy/free functions rather than
> linking to any of the libs, throwing a runtime assertion if the app
> doesn't link to the copy/free stuff that gets used ... throw this
> library into the glib tarball ... it could deal with dbus in addition
> to cairo ... scared yet?

Nah, imagine adding a new enum value in cairo and the pain it would be to go
update that binding library which should still be able to build against older
cairo too.

Havoc Pennington wrote:

> Johan suggested on IRC that the patch to cairo could be changed to use
> dlopen to grab the copy/free functions lazily, to avoid a compile-time
> dependency on glib (and also avoid a runtime dependency, if running in
> an app that doesn't link to glib). It's still a hack, but a working
> and maintainable one, and it doesn't imply a new module to maintain /
> link to just for 4 trivial functions, and doesn't mess up the
> dependency graph. The dlopen could be of NULL not libgobject.so
> (assume the app has already loaded the library), so no tricky issues
> about finding the thing to dlopen would arise.

No dlopen in cairo please.  We'll either link to glib from libcairo.so or
libcairo-glib.so.

Colin Walters wrote:

> Right, this was actually my first thought.  But it doesn't address
> where GIO+cairo using functions would land.  I'm not sure how
> important those are - maybe we could put those in Pango.

The GIO+cairo callbacks can actually go in gio, but cairo-glib is a better
place indeed.

> Any opinion from the GObject side on the option of putting them in
> Pango?  We already have things like a PangoCairoFont GInterface in
> there.

PangoCairoFont is a pangocairo-specific thing.  I hate adding non-pango bits
in pangocairo just for the sake of dep tree.

Kai-Uwe Behrmann wrote:

> Making each application, using Cairo, practical dependent to Glib, appears
> not nice for non Gtk applications. A Cairo package would nearly always
> depend on glib, which makes things like the before mentioned independence
> and upgrading more complicated.

I don't get the logic here at all.  If your distribution decides to build
their cairo with glib, just let them deal with it.  It causes no problem for a
cairo user.

Craig Bradney wrote:

> 100% agree - please keep direct glib dependencies out of the main cairo
> library.

I won't call a compile-time opt-in dependency a "direct glib dependencies".

Chris Wilson wrote:

> There's also been discussion about making gio-friendly streams interface
> for cairo which would seem to also belong in a cairo-glib. Then given
> such a library there is scope for including more cairo utility functions
> that are common to GLib/GObject based applications. For example, having
> a good region management library - i.e. move GdkRegion down the stack
> and improve its memory footprint. So I think the argument against adding
> another small library to the application stack is self-defeating.

Can you elaborate?  The idea for having a lower-level region code was to reuse
it in pixman, cairo, xorg, and gdk.  putting it in cairo-glib solves none of
that problem.


I'm probably make it a separate .so.  The intereface to use it is no different
than having it in cairo.so.  One simply brings in cairo-glib pkg-config
dependencies.  Where the actual code lives is implementation details.  Any
objections to that?

Has to wait till after 1.8 at this point though....

behdad