[cairo] gobject boxed types

[Colin Walters]

On Sat, Sep 13, 2008 at 1:12 PM, Vladimir Vukicevic <vladimir at pobox.com> 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?

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.

On Sat, Sep 13, 2008 at 1:32 PM, Chris Wilson <chris at chris-wilson.co.uk> 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.

(just saw this) Yes, that is a strong argument.  Ok.  Then I need to
build consensus the other way - make sure that the GObject projects
above cairo are ready to add another library dependency.  Pulling in
gtk-devel-list as hopefully the major stakeholders like GTK+,
GooCanvas, HippoCanvas, Clutter etc. are reading.

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.