Re: [matplotlib-devel] PyGTK vs PyGObject

[Michael D. <md...@st...>]

On 10/05/2012 11:40 AM, Damon McDougall wrote:
> On Friday, October 5, 2012, Michael Droettboom wrote:
>
>     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
>>     version).
>>
>>     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 [1] that prevents a
>     bitmap buffer from being transferred to an on screen window, the
>     Gtk3Agg backend will also work.
>
>     http://lists.cairographics.org/archives/cairo/2011-November/022519.html
>
>     BTW -- this report has languished for almost a year.  Does anyone
>     know a better way to get the ear of the pycairo developers?
>
>     Mike
>
>
> 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...
>
We do use pycairo.  It certainly would get around the issue, but 
duplicate a lot of effort that pycairo already handles for us.

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).

Mike