matplotlib-devel Mailing List for matplotlib (Page 2)

Hi Derek,

On Mon, Mar 26, 2012 at 02:50, Derek Homeier
<de...@as...> wrote:
> I was also curious if you had considered moving the docs to a separate package.
> I will propose one for fink;

yes, Debian has a separate package for documentation (since it
requires to be build just on time, whilc mpl requires to be built on
each architecture we support, so splitting the package results in a
lot of saved space). JFYR this is the layout of packages in Debian:

python-matplotlib - the python module
python-matplotlib-data - mpl-data dir + sampeldata + config files + nib + fonts
python-matplotlib-dbg - debug symbols for python extensions
python-matplotlib-doc - all the built doc, in html and pdf formats

Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

On 24.03.2012, at 8:16PM, Sandro Tosi wrote:
> 
> to run tests I use:
> 
> python -c "import matplotlib as m ; m.test(verbosity=1)"
> 
Ah, thanks for the reminder; that looks much more comprehensive! 
Actually the fink testing command requires an exit value of 1 or higher to 
detect errors, so I am using something like 
 "… r=m.test(verbosity=1); sys.exit(len(r.errors+r.failures))"

>> I have another question - I am trying to build a fink package with the documentation
>> and am wondering if "python make.py --small html"
> 
> In debian I use:
> 
> ./make.py --small all
> 
>> actually has any effect?
> 
> what do you mean?
> 
>> This still creates more than 70 MB of documentation, 24 MB in the _images subdir
>> alone, which increases the .deb size by a factor of ~2.5. How are you handling this
>> for the Debian package?
> 
> well, yes, the doc is huge (the debian package size is 52M compressed)
> and that is good; --small helped reducing the package size, setting
> 
>    if small_docs:
>        options = "-D plot_formats=\"[('png', 80)]\""
> 
> which reduced the type and size of the output images.

Indeed, I seemed to remember the regular output was not that much larger, 
but I must have missed all the hires.png and pdf images in the mpl_examples. 
They do account for additional 60-70 MB...
I was also curious if you had considered moving the docs to a separate package. 
I will propose one for fink; since there probably more people are building their 
packages themselves, the savings in build time might already justify that.

Cheers,
					Derek

On Mon, Mar 19, 2012 at 10:08 PM, Pierre Raybaut
<pie...@gm...> wrote:
> Hi all,
>
> Is anyone interested in including the Matplotlib QtDesigner plugin
> which I wrote for Python(x,y)?
>
> The code is quite simple and hasn't evolved for a while now (3 years)
> but apparently it is still appreciated by users even outside
> Python(x,y).
>
> Here are the two files which are necessary to make this plugin work:
> http://code.google.com/p/pythonxy/source/browse/src/python/matplotlib/QtDesigner_Plugins/matplotlibwidget.py
> http://code.google.com/p/pythonxy/source/browse/src/python/matplotlib/QtDesigner_Plugins/PyQt4/plugins/designer/python/matplotlibplugin.py
>
> The directory struture also has its importance:
> http://code.google.com/p/pythonxy/source/browse/#hg%2Fsrc%2Fpython%2Fmatplotlib%2FQtDesigner_Plugins
>
> Cheers,
> Pierre

I have been looking at the matplotlib widget code.  It is very helpful
for putting a widget inside PyQt4 windows.  However, it is lacking any
signals and slots to let you easily connect other Qt4 widgets with the
matplotlib one.  Particularly in Qt Designer, using signals and slots
to connect widgets together is very convenient.

I am willing to implement signals and slots, but I need some advice on
the best approach. So far I see three different approaches that may
work:

1. The simplest is just to manually add slots for common commands in
the widget.  I would also probably add some signals for things like
mouse clicks.  However, this requires manually creating the signals
and slots, and will break if matplotlib changes any of its api.  I
would also need to decide whether to use the matplotlib function
naming rules or the Qt4 ones (or both, since I can give the same
signal multiple names).

2. Integrate the signals and slots directly into matplotlib.  This
would probably involve somehow having matplotlib functions exposed as
signals and/or slots, probably somewhere in the PyQt4/pyside backend.
It would probably entail separating the PyQt4/pyside backend into a
PyQt4/pyside widget and a PyQt4/pyside window that contains that
widget.  All the interaction between settings, buttons, etc would use
signals and slots internally.  Users could then use the widget in
other contexts besides the window, and use the same signals and slots
the window uses.  This would also eliminate the need for a separate
widget to be used for Qt Designer. It would still require manually
specifying the signals and slots. I haven't looked in much detail, but
this is probably not that much more difficult than 1.

3. Make PyQt4 backend use widgets for everything.  Each object would
have all of its functions exposed as signals and slots, and all would
be usable in Qt Designer.  If I understand it correctly, the PyQt4
backend uses Agg for the actual painting, so this would require
implementing an entire new backend, so is probably not a good choice
initially.

Either approach would be

On Sat, Mar 24, 2012 at 18:13, Derek Homeier
<de...@as...> wrote:
> I used the 1.1.0 version to build with the fink Python installation on MaxOS X
> and everything seems to work there, passing the tests at least (does pylab.test('full')
> execute all tests? It seems a rather small number…).

to run tests I use:

python -c "import matplotlib as m ; m.test(verbosity=1)"

> I have another question - I am trying to build a fink package with the documentation
> and am wondering if "python make.py --small html"

In debian I use:

./make.py --small all

> actually has any effect?

what do you mean?

> This still creates more than 70 MB of documentation, 24 MB in the _images subdir
> alone, which increases the .deb size by a factor of ~2.5. How are you handling this
> for the Debian package?

well, yes, the doc is huge (the debian package size is 52M compressed)
and that is good; --small helped reducing the package size, setting

    if small_docs:
        options = "-D plot_formats=\"[('png', 80)]\""

which reduced the type and size of the output images.

Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

Hi Sandro,

> On Fri, Mar 23, 2012 at 03:18, John Hunter <jd...@gm...> wrote:
>> The tarballs for the v1.1.1 release candidate 1 (rc1) are uploaded to and
>> are available for testing and building binaries
>> 
>>  https://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-1.1.1/
>> 
>> After the binaries are up, I'll send out a notice to the users list
>> requesting wider testing, but intrepid developers can begin now.
> 
> I'll start testing debian packaging right away; for our package we
> also need the sampledata tarball: can I reuse the one for 1.1.0 or is
> a new one needed?

I used the 1.1.0 version to build with the fink Python installation on MaxOS X 
and everything seems to work there, passing the tests at least (does pylab.test('full') 
execute all tests? It seems a rather small number…). 

I have another question - I am trying to build a fink package with the documentation 
and am wondering if "python make.py --small html" actually has any effect? 
This still creates more than 70 MB of documentation, 24 MB in the _images subdir 
alone, which increases the .deb size by a factor of ~2.5. How are you handling this 
for the Debian package?

Cheers,
						Derek

On Fri, Mar 23, 2012 at 12:55 PM, Russell E. Owen <ro...@uw...> wrote:

>
> I have uploaded the Mac builds (no Python 2.6 yet; do we really need
> that?). They pass all unit tests and the 32-bit version seems to work
> well with my software.
>
>
Might be nice to upload some python2.6 builds for the actual release, but I
don't see this as necessary for the testers since there are no important
differences between 2.6 and 2.7 as far as v1.1.x is concerned.

JDH

On Fri, Mar 23, 2012 at 12:55 PM, Russell E. Owen <ro...@uw...> wrote:

>
> The included pytz is outdated (and I did not bother to uprev it in the
> binaries I uploaded); would somebody be willing to update that before we
> cut the final releases, or is that considered too risky at this late
> date?
>
>
It feels too risky to me post-rc.  How critical do you think the updates
are?  We are planning on moving our attention to a master release 1.2.x as
soon as this is out, and we can update ahead of that.  And for people who
need the latest, they can always install their own.

JDH

On Fri, Mar 23, 2012 at 12:21 PM, Sandro Tosi <mo...@de...> wrote:

>
> I'll start testing debian packaging right away; for our package we
> also need the sampledata tarball: can I reuse the one for 1.1.0 or is
> a new one needed?
>
>
You can use the same one -- because this is a bugfix release, we have not
introduced any new features, examples or data.  Just bugfixes.

JDH

In article 
<CAG...@ma...>,
 John Hunter <jd...@gm...> wrote:

> On Mon, Mar 19, 2012 at 12:58 PM, John Hunter 
> <jd...@gm...> wrote:
> 
> > I think we are pretty close to cleaning up issues and PRs related to
> > v1.1.x, so I'd like to cut the release candidate this Thursday.  Let's
> > continue to hammer on closing open issues and pull requests, and flag
> > anything that needs to be addressed before the release as
> > "release_critical" in the issue tracker.  If there are show stoppers I am
> > not aware of, chime in.
> >
> >
> The tarballs for the v1.1.1 release candidate 1 (rc1) are uploaded to and
> are available for testing and building binaries
> 
> 
> https://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-1.1.1/

I have uploaded the Mac builds (no Python 2.6 yet; do we really need 
that?). They pass all unit tests and the 32-bit version seems to work 
well with my software.

The included pytz is outdated (and I did not bother to uprev it in the 
binaries I uploaded); would somebody be willing to update that before we 
cut the final releases, or is that considered too risky at this late 
date?

-- Russell

Hi John,

On Fri, Mar 23, 2012 at 03:18, John Hunter <jd...@gm...> wrote:
> The tarballs for the v1.1.1 release candidate 1 (rc1) are uploaded to and
> are available for testing and building binaries
>
>  https://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-1.1.1/
>
> After the binaries are up, I'll send out a notice to the users list
> requesting wider testing, but intrepid developers can begin now.

I'll start testing debian packaging right away; for our package we
also need the sampledata tarball: can I reuse the one for 1.1.0 or is
a new one needed?

Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

On Thu, Mar 22, 2012 at 10:57 PM, Christoph Gohlke <cg...@uc...> wrote:

>
>
> Windows binaries, including the test files, are at <
> http://www.lfd.uci.edu/~**gohlke/pythonlibs/#matplotlib<http://www.lfd.uci.edu/~gohlke/pythonlibs/#matplotlib>
> >**.
>
> All my attempts to upload the files to SF failed (no error report).
>
> I'll run tests later.
>


Hey Christoph, not sure why you are unable to upload, since I have you
designated as a "release manager" on the sf site, but thanks for building
these and I've uploaded these and they are good to go.

I've included this in openSUSE's matplotlib packages, it seems to work great.

-Todd

On Mon, Mar 19, 2012 at 10:08 PM, Pierre Raybaut
<pie...@gm...> wrote:
> Hi all,
>
> Is anyone interested in including the Matplotlib QtDesigner plugin
> which I wrote for Python(x,y)?
>
> The code is quite simple and hasn't evolved for a while now (3 years)
> but apparently it is still appreciated by users even outside
> Python(x,y).
>
> Here are the two files which are necessary to make this plugin work:
> http://code.google.com/p/pythonxy/source/browse/src/python/matplotlib/QtDesigner_Plugins/matplotlibwidget.py
> http://code.google.com/p/pythonxy/source/browse/src/python/matplotlib/QtDesigner_Plugins/PyQt4/plugins/designer/python/matplotlibplugin.py
>
> The directory struture also has its importance:
> http://code.google.com/p/pythonxy/source/browse/#hg%2Fsrc%2Fpython%2Fmatplotlib%2FQtDesigner_Plugins
>
> Cheers,
> Pierre
>
> ---------- Message transféré ----------
> De : todd rme <tod...@gm...>
> Date : 11 mars 2012 12:14
> Objet : [python(x,y)] Upstream Matplotlib Qt Designer Plugin
> À : "python(x,y)" <pyt...@go...>
>
>
> I notice that python(x,y) has a matplotlib plugin for Qt Designer.  I
> think this would be very helpful for general users of matplotlib
> outside of python(x,y).  Is there any possibility of submitting this
> plugin upstream for inclusion with the official matplotlib release?
> That way people who aren't using python(x,y) (for instance Linux users
> who are using their official distribution python packages) could
> benefit from the plugin as well.  Thank you very much.
>
> -Todd
>
> --
> You received this message because you are subscribed to the Google
> Groups "python(x,y)" group.
> To post to this group, send email to pyt...@go....
> To unsubscribe from this group, send email to
> pyt...@go....
> For more options, visit this group at
> http://groups.google.com/group/pythonxy?hl=en.

On 3/22/2012 7:18 PM, John Hunter wrote:
>
>
> On Mon, Mar 19, 2012 at 12:58 PM, John Hunter <jd...@gm...
> <mailto:jd...@gm...>> wrote:
>
>     I think we are pretty close to cleaning up issues and PRs related to
>     v1.1.x, so I'd like to cut the release candidate this Thursday.
>       Let's continue to hammer on closing open issues and pull requests,
>     and flag anything that needs to be addressed before the release as
>     "release_critical" in the issue tracker.  If there are show stoppers
>     I am not aware of, chime in.
>
>
> The tarballs for the v1.1.1 release candidate 1 (rc1) are uploaded to
> and are available for testing and building binaries
>
> https://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-1.1.1/
>
> After the binaries are up, I'll send out a notice to the users list
> requesting wider testing, but intrepid developers can begin now.
>
> The reference github commit for rc1 is
> https://github.com/matplotlib/matplotlib/commit/c5593eea91d82559c6e30e999635b93a35a13bc9
>
> There was a heroic effort by Michael Droetboom and Thomas Robitaille in
> the last two days to get past the freetype version and platform specific
> rendering issues, mainly revolving around anti-aliasing, and we are
> pretty close to there, so going forward we can expect almost all of the
> tests to pass for almost all of the developers, and have a mechanism for
> adding freetype version dependent known fails.  This will make our tests
> much more useful.  Thomas in particular did a crazy amount of testing on
> every conceivable combination of freetype settings and versions which
> really pushed the success of this effort, and Michael stayed right there
> with him committing fixes faster than any human could test.
>
> https://github.com/matplotlib/matplotlib/pull/779
>
> This will be the last release supporting python 2.4 and in all
> likelihood the last of the 1.1.x line, so I'd like to make it rock
> solid.  Testing will be appreciated.  For those of you who prefer the
> github interface/workflow, I'm opening up an "open thread" issue
>
> https://github.com/matplotlib/matplotlib/issues/791
>
> Thanks to all who've contributed -- I'll work up detailed notes for the
> real release, hopefully next week.  Russell and Christoph, you should be
> able to access to file manager interface directly on sf to upload your
> binaries, but let me know if you have any troubles.
>
> JDH
>

Hi John,

Windows binaries, including the test files, are at 
<http://www.lfd.uci.edu/~gohlke/pythonlibs/#matplotlib>.

All my attempts to upload the files to SF failed (no error report).

I'll run tests later.

Christoph

On Mon, Mar 19, 2012 at 12:58 PM, John Hunter <jd...@gm...> wrote:

> I think we are pretty close to cleaning up issues and PRs related to
> v1.1.x, so I'd like to cut the release candidate this Thursday.  Let's
> continue to hammer on closing open issues and pull requests, and flag
> anything that needs to be addressed before the release as
> "release_critical" in the issue tracker.  If there are show stoppers I am
> not aware of, chime in.
>
>
The tarballs for the v1.1.1 release candidate 1 (rc1) are uploaded to and
are available for testing and building binaries


https://sourceforge.net/projects/matplotlib/files/matplotlib/matplotlib-1.1.1/

After the binaries are up, I'll send out a notice to the users list
requesting wider testing, but intrepid developers can begin now.

The reference github commit for rc1 is
https://github.com/matplotlib/matplotlib/commit/c5593eea91d82559c6e30e999635b93a35a13bc9

There was a heroic effort by Michael Droetboom and Thomas Robitaille in the
last two days to get past the freetype version and platform specific
rendering issues, mainly revolving around anti-aliasing, and we are pretty
close to there, so going forward we can expect almost all of the tests to
pass for almost all of the developers, and have a mechanism for adding
freetype version dependent known fails.  This will make our tests much more
useful.  Thomas in particular did a crazy amount of testing on every
conceivable combination of freetype settings and versions which really
pushed the success of this effort, and Michael stayed right there with him
committing fixes faster than any human could test.

https://github.com/matplotlib/matplotlib/pull/779

This will be the last release supporting python 2.4 and in all likelihood
the last of the 1.1.x line, so I'd like to make it rock solid.  Testing
will be appreciated.  For those of you who prefer the github
interface/workflow, I'm opening up an "open thread" issue

https://github.com/matplotlib/matplotlib/issues/791

Thanks to all who've contributed -- I'll work up detailed notes for the
real release, hopefully next week.  Russell and Christoph, you should be
able to access to file manager interface directly on sf to upload your
binaries, but let me know if you have any troubles.

JDH

Hi all,

just to let you know that the videos from the PyData workshop we held
at Google a couple of weeks ago are now online (not all talks are up
yet, so watch the page over the next few days if a talk you wanted to
see isn't posted yet):

http://marakana.com/s/2012_pydata_workshop,1090/index.html

The panel discussion with Guido that we talked about on these lists is
in there; I hope to write up a short summary about it soon.

Many thanks to Simeon Franklin and the rest of the Marakana team for
doing all this work (for free)!

Cheers,

f

In article 
<CAG...@ma...>,
 John Hunter <jd...@gm...> wrote:

> I think we are pretty close to cleaning up issues and PRs related to
> v1.1.x, so I'd like to cut the release candidate this Thursday.  Let's
> continue to hammer on closing open issues and pull requests, and flag
> anything that needs to be addressed before the release as
> "release_critical" in the issue tracker.  If there are show stoppers I am
> not aware of, chime in.
> 
> Thanks,
> JDH
> 
> ---------------------------------------------------------------------
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here 
> http://p.sf.net/sfu/sfd2d-msazure
> ---------------------------------------------------------------------
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Let me know when the source is ready to be pulled (and a link to 
instructions would be helpful) and I'll cut the Mac binaries.

-- Russell

I just put a pull request up that resolves these tests for me: #779.  If 
it's working for others, we should go ahead and merge that into v1.1.x 
before the release.

Mike

On 03/20/2012 09:49 AM, Michael Droettboom wrote:
> We seem to have a large number of failing tests due to the recent 
> fixes to the snapping behavior.  Mainly these just need to be triaged 
> and have the baseline images replaced.  I'm going to see how far I get 
> on this today.
>
> Mike
>
> On 03/19/2012 01:58 PM, John Hunter wrote:
>> I think we are pretty close to cleaning up issues and PRs related to 
>> v1.1.x, so I'd like to cut the release candidate this Thursday. 
>>  Let's continue to hammer on closing open issues and pull requests, 
>> and flag anything that needs to be addressed before the release as 
>> "release_critical" in the issue tracker.  If there are show stoppers 
>> I am not aware of, chime in.
>>
>> Thanks,
>> JDH
>>
>>
>> ------------------------------------------------------------------------------
>> This SF email is sponsosred by:
>> Try Windows Azure free for 90 days Click Here
>> http://p.sf.net/sfu/sfd2d-msazure
>>
>>
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
>
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
> http://p.sf.net/sfu/sfd2d-msazure
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Have a look at #779.  Can you let me know if this resolves the tests for 
you?

https://github.com/matplotlib/matplotlib/pull/779

Mike

On 03/20/2012 09:48 AM, Michael Droettboom wrote:
> I've mainly done this using a thumbnailing tool like gthumb on one 
> side of the screen and a console to copy files on the other.  Since 
> the diff images are already generated, it's generally not so bad.  I'm 
> going to try to get all tests passing before the release if possible.  
> Wish me luck.  :)
>
> There are some related bug reports to this in #743 and #744.
>
> Mike
>
> On 03/14/2012 05:38 PM, Benjamin Root wrote:
>> So, I just tried running the test suite on matplotlib and it came 
>> back with 70+ failures.  I personally don't have the time or the 
>> focus to go through them all, but I suspect most if not all are 
>> related to some "snapping" fixes as most of the diff images seem to 
>> be related to changes in the graph borders and slight changes in text 
>> placement.  Maybe it would be useful to come up with a tool that 
>> could process through the result_images directory and display the 
>> images and their diffs and help us replace the images we deem as 
>> acceptable (or bump thresholds if we don't want to replace the image).
>>
>> What do others think? Maybe someone already has such a script?
>>
>> Ben Root
>>
>>
>> ------------------------------------------------------------------------------
>> Virtualization&  Cloud Management Using Capacity Planning
>> Cloud computing makes use of virtualization - but cloud computing
>> also focuses on allowing computing to be delivered as a service.
>> http://www.accelacomm.com/jaw/sfnl/114/51521223/
>>
>>
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
>
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
> http://p.sf.net/sfu/sfd2d-msazure
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

We seem to have a large number of failing tests due to the recent fixes 
to the snapping behavior.  Mainly these just need to be triaged and have 
the baseline images replaced.  I'm going to see how far I get on this today.

Mike

On 03/19/2012 01:58 PM, John Hunter wrote:
> I think we are pretty close to cleaning up issues and PRs related to 
> v1.1.x, so I'd like to cut the release candidate this Thursday.  Let's 
> continue to hammer on closing open issues and pull requests, and flag 
> anything that needs to be addressed before the release as 
> "release_critical" in the issue tracker.  If there are show stoppers I 
> am not aware of, chime in.
>
> Thanks,
> JDH
>
>
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
> http://p.sf.net/sfu/sfd2d-msazure
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

I've mainly done this using a thumbnailing tool like gthumb on one side 
of the screen and a console to copy files on the other.  Since the diff 
images are already generated, it's generally not so bad.  I'm going to 
try to get all tests passing before the release if possible.  Wish me 
luck.  :)

There are some related bug reports to this in #743 and #744.

Mike

On 03/14/2012 05:38 PM, Benjamin Root wrote:
> So, I just tried running the test suite on matplotlib and it came back 
> with 70+ failures.  I personally don't have the time or the focus to 
> go through them all, but I suspect most if not all are related to some 
> "snapping" fixes as most of the diff images seem to be related to 
> changes in the graph borders and slight changes in text placement.  
> Maybe it would be useful to come up with a tool that could process 
> through the result_images directory and display the images and their 
> diffs and help us replace the images we deem as acceptable (or bump 
> thresholds if we don't want to replace the image).
>
> What do others think? Maybe someone already has such a script?
>
> Ben Root
>
>
> ------------------------------------------------------------------------------
> Virtualization&  Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Hi all,

Is anyone interested in including the Matplotlib QtDesigner plugin
which I wrote for Python(x,y)?

The code is quite simple and hasn't evolved for a while now (3 years)
but apparently it is still appreciated by users even outside
Python(x,y).

Here are the two files which are necessary to make this plugin work:
http://code.google.com/p/pythonxy/source/browse/src/python/matplotlib/QtDesigner_Plugins/matplotlibwidget.py
http://code.google.com/p/pythonxy/source/browse/src/python/matplotlib/QtDesigner_Plugins/PyQt4/plugins/designer/python/matplotlibplugin.py

The directory struture also has its importance:
http://code.google.com/p/pythonxy/source/browse/#hg%2Fsrc%2Fpython%2Fmatplotlib%2FQtDesigner_Plugins

Cheers,
Pierre

---------- Message transféré ----------
De : todd rme <tod...@gm...>
Date : 11 mars 2012 12:14
Objet : [python(x,y)] Upstream Matplotlib Qt Designer Plugin
À : "python(x,y)" <pyt...@go...>


I notice that python(x,y) has a matplotlib plugin for Qt Designer.  I
think this would be very helpful for general users of matplotlib
outside of python(x,y).  Is there any possibility of submitting this
plugin upstream for inclusion with the official matplotlib release?
That way people who aren't using python(x,y) (for instance Linux users
who are using their official distribution python packages) could
benefit from the plugin as well.  Thank you very much.

-Todd

--
You received this message because you are subscribed to the Google
Groups "python(x,y)" group.
To post to this group, send email to pyt...@go....
To unsubscribe from this group, send email to
pyt...@go....
For more options, visit this group at
http://groups.google.com/group/pythonxy?hl=en.

I think we are pretty close to cleaning up issues and PRs related to
v1.1.x, so I'd like to cut the release candidate this Thursday.  Let's
continue to hammer on closing open issues and pull requests, and flag
anything that needs to be addressed before the release as
"release_critical" in the issue tracker.  If there are show stoppers I am
not aware of, chime in.

Thanks,
JDH

Assuming there's no bugs, this doesn't look like the kind of thing that 
the snapping algorithm would cause or address.  Snapping is only 
supposed to kick in when the lines are rectilinear (i.e. perfectly 
horizontal or vertical) which none of the lines in this plot appear to 
be.  This plot actually looks "correct" to me -- it would be nice if the 
axis at the bottom had less stair-stepping, which some sort of gamma 
correction or perhaps tweaking of line width might help, but we don't 
currently do anything like that.

Mike

On 03/17/2012 03:58 PM, Benjamin Root wrote:
>
>
> On Sat, Mar 17, 2012 at 2:49 PM, Benjamin Root <ben...@ou... 
> <mailto:ben...@ou...>> wrote:
>
>     I know this has been addressed so many times, but as I was testing
>     out mplot3d in v1.1.x, I swear the axes lines were aliasing like
>     crazy at some viewing angles.  If it is just mplot3d, then
>     probably should not hold up the bugfixes release, but maybe we
>     should get some eyes on the test results before releasing???
>
>     Ben Root 
>
>
>
> I have attached an image of the aliasing here.  I am going to test to 
> see if the recent snapping changes caused this.
>
> Ben Root
>
>
>
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
> http://p.sf.net/sfu/sfd2d-msazure
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

I know this has been addressed so many times, but as I was testing out
mplot3d in v1.1.x, I swear the axes lines were aliasing like crazy at some
viewing angles.  If it is just mplot3d, then probably should not hold up
the bugfixes release, but maybe we should get some eyes on the test results
before releasing???

Ben Root

Hi,

Here is an example to report a small bug in colorbars: ticks outside the "boundaries" doesn't display. "Boundaries" doesn't matter, only "values" do (cf example). It appends only when values and boundaries are differents (usefull for what I'm doing).

import scipy
from matplotlib import pyplot

pyplot.imshow(scipy.lena())
cbar_boundaries = scipy.linspace(-1000,1000,100)
cbar_values = scipy.linspace(0,255,99)
cb = pyplot.colorbar(boundaries=cbar_boundaries, values=cbar_values)
cb.set_ticks([-500, 50, 500])
pyplot.show()

Cheers,
Benoît