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?
Thanks for your help.
-Todd
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.
BTW – this report has languished for almost a year. Does anyone
know a better way to get the ear of the pycairo developers?
Mike
···
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?
http://lists.cairographics.org/archives/cairo/2011-November/022519.html
I had good response time when I went straight to their IRC channel one time (I don’t remember the location, it was listed on their dev pages, I think).
Ben Root
···
On Fri, Oct 5, 2012 at 9:57 AM, Michael Droettboom <mdroe@…31…> 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](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…
···
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](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
–
Damon McDougall
http://www.damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom
It turns out that this was addressed in git last May and it does in
fact work with matplotlib. Once a new pycairo release is out and
makes it into the package managers, the Gtk3Agg backend should work
on Python 3.
Mike
···
On 10/05/2012 09:57 AM, Michael
Droettboom wrote:
The new Gtk3Cairo backend uses PyGObject and works under Python
- (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.
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?
http://lists.cairographics.org/archives/cairo/2011-November/022519.html
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
···
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](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…
Of course. I was merely asking to qualm my curiosity rather than
suggesting a major codebase re-haul. Thanks for looking into this.
···
On Fri, Oct 5, 2012 at 5:51 PM, Michael Droettboom <mdroe@...31...> wrote:
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
--
Damon McDougall
http://www.damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom
A bit OT -- but have you added, and or does pyCairo have, numpy-array awareness?
i.e. is there an efficient way to pass a lo tof coordinate parie,s etc
to pyCairo?
Just wondering, 'cause I'm trying to decide on a rendering lib to use
for another project.
-Chris
···
On Fri, Oct 5, 2012 at 9:51 AM, Michael Droettboom <mdroe@...31...> wrote:
We do use pycairo. It certainly would get around the issue, but duplicate a
lot of effort that pycairo already handles for us.
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chris.Barker@...236...
Not as far as I know for path data. The upcoming pycairo version supports using image buffers (which can be Numpy arrays), but that's not helpful for drawing lines etc.
Mike
···
On 10/05/2012 02:53 PM, Chris Barker wrote:
On Fri, Oct 5, 2012 at 9:51 AM, Michael Droettboom <mdroe@...31...> wrote:
We do use pycairo. It certainly would get around the issue, but duplicate a
lot of effort that pycairo already handles for us.
A bit OT -- but have you added, and or does pyCairo have, numpy-array awareness?
i.e. is there an efficient way to pass a lo tof coordinate parie,s etc
to pyCairo?
Just wondering, 'cause I'm trying to decide on a rendering lib to use
for another project.
Thx-I did see some add-on code for using numpy arrays with pycairo once.
Maybe I'll look for that, and/or work on add-on code myself.
-Chris
···
On Oct 5, 2012, at 12:25 PM, Michael Droettboom <mdroe@...31...> wrote:
On 10/05/2012 02:53 PM, Chris Barker wrote:
The upcoming pycairo version
supports using image buffers (which can be Numpy arrays), but that's not
helpful for drawing lines etc.
This would be much appreciated. We should leave the pure Python implementation in for those who don't have the cairo C headers installed or findable.
Mike
···
On 10/06/2012 02:22 PM, Chris Barker wrote:
On Oct 5, 2012, at 12:25 PM, Michael Droettboom <mdroe@...31...> wrote:
On 10/05/2012 02:53 PM, Chris Barker wrote:
The upcoming pycairo version
supports using image buffers (which can be Numpy arrays), but that's not
helpful for drawing lines etc.
Thx-I did see some add-on code for using numpy arrays with pycairo once.
Maybe I'll look for that, and/or work on add-on code myself.