<div dir="ltr"><br><br><div class="gmail_quote">2008/9/13 Colin Walters <span dir="ltr">&lt;<a href="mailto:walters@verbum.org">walters@verbum.org</a>&gt;</span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi,<br>
<br>
We had a short discussion about this on #gtk+ a few days ago.<br>
Basically, it would greatly help the GObject-based stack above Cairo<br>
(GTK+, HippoCanvas, GooCanvas, Clutter, etc.) if we had official<br>
GObject &quot;boxed&quot; types for Cairo objects.<br>
<br>
This is necessary because the GTypes are used in things like signals<br>
to specify argument types, and language bindings need that data. &nbsp;Now,<br>
one possibility Matthias Clasen suggested would be to put these in<br>
GDK, which would be somewhat tricky from a layering perspective<br>
(neither Pango nor Clutter for example currently depend on GDK as far<br>
as I know), but might be workable. &nbsp;Another possibility is to put them<br>
in Cairo itself, optionally enabled.</blockquote><div><br>A reflection of this problem will appear at language bindings level.&nbsp; If we put this in Cairo itself, then pycairo should add support for this and optionally depend on pygobject.&nbsp; It sounds fine to me, but I hope the pycairo maintainer is OK with it too! ;-)<br>
<br>But I think this is a good idea; currently GooCanvas is defining its own private GTypes for Cairo stuff, which clearly are not specific to GooCanvas...<br></div></div><br>-- <br>Gustavo J. A. M. Carneiro<br>INESC Porto, Telecommunications and Multimedia Unit<br>
&quot;The universe is always one step beyond logic.&quot; -- Frank Herbert<br>
</div>