matplotlib-devel Mailing List for matplotlib (Page 4)

On Thu, Oct 11, 2012 at 10:49 PM, Michael Droettboom <md...@st...> wrote:
> I have a proof-of-concept way to make interactive plots in the browser work
> using transparent PNGs described here:
>
> http://mdboom.github.com/blog/2012/10/11/matplotlib-in-the-browser-its-coming/
>
> No PRs yet, because this is miles from ready for that, but it would be
> helpful to get some feedback about how this works in different
> browsers/platforms/network environments etc.
As a bit of spiritual support for the underlying concept, I mostly use
matplotlib via exactly this mechanism, today. Except I didn't want to
modify matplotlib, so my solution is a bit more elaborate:
http://xpra.org/
There's an astonishing amount of nonsense involved in setting up a
headless X server, registering as a window manager and compositing
manager, fighting with the X keyboard model, etc., but at the end of
the day it just works by shipping PNG-style compressed screenshots
over the wire in one direction, and input events over the wire in the
other. Perhaps surprisingly, the result is dramatically more usable
over remote links than vanilla X forwarding is, and it's very
maintainable. So +1 to this approach.
-n

Oh, that is *much* better. Thank you!
Ben Root
On Fri, Oct 12, 2012 at 8:44 AM, Michael Droettboom <md...@st...> wrote:
> It is now fixed. I just uploaded a higher resolution image of the same
> thing.
>
> Mike
>
> On 10/10/2012 04:31 PM, Damon McDougall wrote:
> > On Wed, Oct 10, 2012 at 7:36 PM, Benjamin Root <ben...@ou...> wrote:
> >> Looks like github has changed the layout of the default landing page
> for any
> >> github account. This now has the account's profile image shown much
> larger
> >> than originally intended. Our front page now has a very pixelated logo
> on
> >> display. Given how much we pride ourselves on high-quality images, we
> >> should probably fix this:
> >>
> >> https://github.com/matplotlib
> >>
> >> Cheers!
> >> Ben Root
> > This has been bugging me for a while...
> >
>
>
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

It is now fixed. I just uploaded a higher resolution image of the same 
thing.
Mike
On 10/10/2012 04:31 PM, Damon McDougall wrote:
> On Wed, Oct 10, 2012 at 7:36 PM, Benjamin Root <ben...@ou...> wrote:
>> Looks like github has changed the layout of the default landing page for any
>> github account. This now has the account's profile image shown much larger
>> than originally intended. Our front page now has a very pixelated logo on
>> display. Given how much we pride ourselves on high-quality images, we
>> should probably fix this:
>>
>> https://github.com/matplotlib
>>
>> Cheers!
>> Ben Root
> This has been bugging me for a while...
>

It is not clear to me that the stream of PNGs will win in the end. If
you make a single static plot of a large data set, that is way better
than trying to send the data to the browser and rendering it there.
But if you have to send hundreds or thousands of PNGs to get
interactivity, that benefit may be washed out. Especially if you have
multiple users interacting with plots - the server could quickly grind
to a halt. I think we should do tests to see how bad it gets, taking
into account the multiple user question. The one performance benefit
that I can think of is that you can tune the level of interactivity to
limit the data that comes back. For large data sets, users might be
willing to settle for less interactivity. That option doesn't exist
when you send all the data back.
Cheers,
Brian
On Thu, Oct 11, 2012 at 2:49 PM, Michael Droettboom <md...@st...> wrote:
> I have a proof-of-concept way to make interactive plots in the browser work
> using transparent PNGs described here:
>
> http://mdboom.github.com/blog/2012/10/11/matplotlib-in-the-browser-its-coming/
>
> No PRs yet, because this is miles from ready for that, but it would be
> helpful to get some feedback about how this works in different
> browsers/platforms/network environments etc.
>
> Mike
>
> _______________________________________________
> IPython-dev mailing list
> IPy...@sc...
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-- 
Brian E. Granger
Cal Poly State University, San Luis Obispo
bgr...@ca... and ell...@gm...

On 10/11/12 4:49 PM, Michael Droettboom wrote:
> I have a proof-of-concept way to make interactive plots in the browser
> work using transparent PNGs described here:
>
> http://mdboom.github.com/blog/2012/10/11/matplotlib-in-the-browser-its-coming/
>
> No PRs yet, because this is miles from ready for that, but it would be
> helpful to get some feedback about how this works in different
> browsers/platforms/network environments etc.
>
A sample implementation using websockets instead of polling is here:
https://gist.github.com/3875846
It still requests the file, which causes a delay. I think doing a png 
diff sounds like a great idea. What if we also transfer the png diff 
over the websocket connection (maybe in a binary frame)?
Thanks,
Jason

I have a proof-of-concept way to make interactive plots in the browser 
work using transparent PNGs described here:
http://mdboom.github.com/blog/2012/10/11/matplotlib-in-the-browser-its-coming/
No PRs yet, because this is miles from ready for that, but it would be 
helpful to get some feedback about how this works in different 
browsers/platforms/network environments etc.
Mike

On Wed, Oct 10, 2012 at 7:36 PM, Benjamin Root <ben...@ou...> wrote:
> Looks like github has changed the layout of the default landing page for any
> github account. This now has the account's profile image shown much larger
> than originally intended. Our front page now has a very pixelated logo on
> display. Given how much we pride ourselves on high-quality images, we
> should probably fix this:
>
> https://github.com/matplotlib
>
> Cheers!
> Ben Root
This has been bugging me for a while...
-- 
Damon McDougall
http://www.damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

Hi Ben,
Seems like github is down at the moment, and I wanted to relay something I
> have noticed in some of the PEP8 changes:
>
I'm guessing it's on one of my PR
>
> "The preferred place to break around a binary operator is *after* the
> operator, not before it."
>
I am seeing some proposed changes that would put the binary operator on the
> next line (particularly in backend_bases.py).
>
That's an artifact of autopep8 which I use on the big files to correct the
pep8 problems.
If you could be more precised of which PR and which line this problem
occurs, I can fix it.
Thanks,
Nelle
> Cheers!
> Ben Root
>
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

Seems like github is down at the moment, and I wanted to relay something I
have noticed in some of the PEP8 changes:
"The preferred place to break around a binary operator is *after* the
operator, not before it."
I am seeing some proposed changes that would put the binary operator on the
next line (particularly in backend_bases.py).
Cheers!
Ben Root

Looks like github has changed the layout of the default landing page for
any github account. This now has the account's profile image shown much
larger than originally intended. Our front page now has a very pixelated
logo on display. Given how much we pride ourselves on high-quality images,
we should probably fix this:
https://github.com/matplotlib
Cheers!
Ben Root

On 2012年10月09日 4:38 PM, Benjamin Root wrote:
>
>
> On Tuesday, October 9, 2012, Mike Kaufman wrote:
>
> On 10/9/12 9:42 PM, Eric Firing wrote:
> > On 2012年10月09日 3:03 PM, Mike Kaufman wrote:
>
> >> clf()
> >> x = arange(10)
> >> subplot(211)
> >> plot(x, x)
> >> tick_params(right='off') # works.
> >>
> >> subplot(212)
> >> semilogy(x, x)
> >> tick_params(right='off') # doesn't work!
> >> draw()
> >
> >
> > You need to specify an additional kwarg, which='both'. The default is
> > "major" only, but log axes use minor and major ticks.
>
> You are so right. And now that I think about it, this has bitten me (and
> been solved by me) before. And I think the reason has got to be that the
> regular plot simply doesn't have any minor ticks by default. That's
> bugged me because (correct me if I'm wrong) many of our competitors'
> (e.g. Matlab, IDL) plots do have minor ticks as a default.
>
> What do you think about changing the default of tick_params to 'both',
> and perhaps add minor ticks (I suggest a single minor between each
> major) to regular plots as a default?
>
> M
>
>
>
> I'd +1 that MEP. Though, a place where it might not makes sense is bar
> charts. Something to think about.
I would not support making minor ticks appear by default on linear axes. 
 I don't think Matlab does it; but more importantly, (1) doing a good 
job of automatic tick location would get more difficult, and (2) minor 
ticks on linear axes are usually visual clutter, not good design.
Regarding defaulting to "both", the problem is that this would make 
sense only for some of the parameters. For example, one would not want 
"both" to be the default when setting tick length, and might not want it 
when setting width. Granted, there are more options that one typically 
would want to apply to both than that one would not, so "both" might 
still be a better default.
Eric
>
> Ben Root
>
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
>
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

On Tuesday, October 9, 2012, Mike Kaufman wrote:
> On 10/9/12 9:42 PM, Eric Firing wrote:
> > On 2012年10月09日 3:03 PM, Mike Kaufman wrote:
>
> >> clf()
> >> x = arange(10)
> >> subplot(211)
> >> plot(x, x)
> >> tick_params(right='off') # works.
> >>
> >> subplot(212)
> >> semilogy(x, x)
> >> tick_params(right='off') # doesn't work!
> >> draw()
> >
> >
> > You need to specify an additional kwarg, which='both'. The default is
> > "major" only, but log axes use minor and major ticks.
>
> You are so right. And now that I think about it, this has bitten me (and
> been solved by me) before. And I think the reason has got to be that the
> regular plot simply doesn't have any minor ticks by default. That's
> bugged me because (correct me if I'm wrong) many of our competitors'
> (e.g. Matlab, IDL) plots do have minor ticks as a default.
>
> What do you think about changing the default of tick_params to 'both',
> and perhaps add minor ticks (I suggest a single minor between each
> major) to regular plots as a default?
>
> M
>
>
>
I'd +1 that MEP. Though, a place where it might not makes sense is bar
charts. Something to think about.
Ben Root

On 10/9/12 9:42 PM, Eric Firing wrote:
> On 2012年10月09日 3:03 PM, Mike Kaufman wrote:
>> clf()
>> x = arange(10)
>> subplot(211)
>> plot(x, x)
>> tick_params(right='off') # works.
>>
>> subplot(212)
>> semilogy(x, x)
>> tick_params(right='off') # doesn't work!
>> draw()
>
>
> You need to specify an additional kwarg, which='both'. The default is
> "major" only, but log axes use minor and major ticks.
You are so right. And now that I think about it, this has bitten me (and 
been solved by me) before. And I think the reason has got to be that the 
regular plot simply doesn't have any minor ticks by default. That's 
bugged me because (correct me if I'm wrong) many of our competitors' 
(e.g. Matlab, IDL) plots do have minor ticks as a default.
What do you think about changing the default of tick_params to 'both', 
and perhaps add minor ticks (I suggest a single minor between each 
major) to regular plots as a default?
M

On 2012年10月09日 3:03 PM, Mike Kaufman wrote:
>
> The example code should explain the problem.
> tick_params(), at least for the ticks themselves, is ignored by log plots.
>
> clf()
> x = arange(10)
> subplot(211)
> plot(x, x)
> tick_params(right='off') # works.
>
> subplot(212)
> semilogy(x, x)
> tick_params(right='off') # doesn't work!
> draw()
You need to specify an additional kwarg, which='both'. The default is 
"major" only, but log axes use minor and major ticks.
Eric
>
> M
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

The example code should explain the problem.
tick_params(), at least for the ticks themselves, is ignored by log plots.
clf()
x = arange(10)
subplot(211)
plot(x, x)
tick_params(right='off') # works.
subplot(212)
semilogy(x, x)
tick_params(right='off') # doesn't work!
draw()
M

According to the schedule (which I don't consider very rigid), we're set 
to tag rc3 today.
I see there are a number of PRs tagged for 1.2.x that it would be nice 
to polish a little before putting in, so I'm inclined to push back the 
rc3 tagging for a bit. I'm attending a conference Tues-Thurs, so 
probably wouldn't be able to look at this until Friday at the earliest, 
but I think that will give sufficient time to make these last few PRs as 
good as they can possibly be.
In the meantime, please label any PRs or Issues you're aware of that 
should go into 1.2.0 as 1.2.x -- I've done a few, but it's easy to miss 
things if I'm not entirely familiar with the content of a PR.
Mike

On 10/06/2012 02:22 PM, Chris Barker wrote:
> On Oct 5, 2012, at 12:25 PM, Michael Droettboom <md...@st...> 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.
>
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 Oct 5, 2012, at 12:25 PM, Michael Droettboom <md...@st...> 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.
-Chris

On 10/05/2012 02:53 PM, Chris Barker wrote:
> On Fri, Oct 5, 2012 at 9:51 AM, Michael Droettboom <md...@st...> 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.
>
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 Fri, Oct 5, 2012 at 9:51 AM, Michael Droettboom <md...@st...> 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.
-Chris
-- 
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
Chr...@no...

On Fri, Oct 5, 2012 at 5:51 PM, Michael Droettboom <md...@st...> 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
Of course. I was merely asking to qualm my curiosity rather than
suggesting a major codebase re-haul. Thanks for looking into this.
-- 
Damon McDougall
http://www.damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

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

On 10/05/2012 09:57 AM, 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
>
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 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...
-- 
Damon McDougall
http://www.damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

On Fri, Oct 5, 2012 at 9:57 AM, Michael Droettboom <md...@st...> 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
>
>
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