On 10/05/2012 11:40 AM, Damon McDougall
On Friday, October 5, 2012, Michael Droettboom wrote:
We do use pycairo. It certainly would get around the issue, but
duplicate a lot of effort that pycairo already handles for us.
On 10/05/2012 06:38 AM, todd rme wrote:
I am trying to do some experimental packages with python 3 and the
latest RC, and I am trying to figure out the situation with some of
the backends. Some are obvious, like wxwidgets and PyQt (Qt3
The issue I am running into is with the gtk backend PyGTK is
deprecated. According to the website, all development halted a year
and a half ago and they say to use PyGObject instead. PyGTK, as far
as I can tell, does not support Python 3 or GTK 3. PyGObject,
however, supports both. So I was wondering what I should be doing
with this backend. Does matplotlib support PyGObject, or should the
GTK backends just be disabled on Python 3 builds?
The new Gtk3Cairo backend uses PyGObject and works under
Python 3. (This refers to Gtk version 3, which is also only
supported by PyGObject -- the backend could perhaps have been
called PyGObject, but in fact the toolkit used is still Gtk,
so the naming is perhaps a bit confusing). The older pygtk
backend still ships with Python 3, but a warning is displayed
when the user attempts to use it.
Once PyGObject/PyCairo addresses a shortcoming  that
prevents a bitmap buffer from being transferred to an on
screen window, the Gtk3Agg backend will also work.
BTW -- this report has languished for almost a year. Does
anyone know a better way to get the ear of the pycairo
Do we use pycairo to interface with the Cairo library? Is
there any reason we don't use the C (or C++, I can't remember
what libcairo is written in) directly?
This may get around the issue, but it'd be a lot of work...
Now that I've seen that the bug has been fixed in pycairo's git (see
my earlier message), I'm comfortable just waiting for the next
pycairo release (assuming it's not too far off).