[matplotlib-devel] Why are image coordinates rounded to integers?

2009-08-31 Thread Jouni K . Seppänen 
Hi,

Mike Fitzgerald reported bug #2832896 and has been investigating its
causes:

https://sourceforge.net/tracker/?func=detail&aid=2832896&group_id=80706&atid=560720

The problem is that images are not drawn at exactly the same coordinates
as other artists, so markers drawn on top of images are slightly off in
pdf and eps output. Apparently this can be fixed, at least to some
degree, by removing the round(...) operations from

renderer.draw_image(gc, round(l), round(b), im)

in _AxesImageBase.draw and making a slightly more involved change in
AxesImage.make_image (the details are in the bug report). I haven't had
time to investigate what this does to other backends, but I imagine the
rounding would be necessary for raster backends.

Can someone who is more familiar with the image machinery comment on the
matter? Do we need some kind of vector/raster indication in the backends,
in addition to the get_image_magnification method?

-- 
Jouni K. Seppänen
http://www.iki.fi/jks


--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Bugs in Qt4 backend with the latest PyQt release

2009-08-31 Thread william ratcliff 
Hi!  I just installed matplotlib version .99 (windows vista, python25,
32bit) and found that
this line was missing:
QtGui.qApp.processEvents()

Adding it sped the QT4Agg backend back to reasonable speeds--but it still
seems a bit slow.  Otherwise, I am using the excellent Python(x,y) 2.1.14
release for my python distribution on this machine.  Could this line be
added back?

Cheers,
William


On Tue, Aug 19, 2008 at 4:58 AM, Pierre Raybaut wrote:

> Hi Darren,
>
> 2008/8/18 Darren Dale :
> > Nevermind. It turns out its not exactly poor performance, but for some
> reason
> > the gui events were not getting processed as frequently on windows. Maybe
> Qt
> > changed something in an attempt to optimize performance.
> >
> > I applied a patch in svn 6043, but its a really simple fix. At the end of
> > backend_qt4agg.FigureCanvasQTAgg.draw, after self.update(), add this
> line:
> >
> >QtGui.qApp.processEvents()
> >
> > It seemed to improve things on my windows laptop,  but let me know if it
> fixes
> > the problem for you.
>
> Good work Darren, thanks, it works perfectly!
> That is great news because I found (and reported) this bug three
> months ago, so I was beginning to worry about the future of Qt4
> backend.
> Now I can consider updating PyQt in Python(x,y).
>
> > I forgot to mention, the svg icons display fine for me with windows xp,
> > matplotlib-0.98.
>
> Forget about it, I've just found out that this is related to one of my
> own-made packages.
>
> Thanks
> Pierre
>
> -
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ___
> Matplotlib-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Bugs in Qt4 backend with the latest PyQt release

2009-08-31 Thread Darren Dale 
Hi William,

On Mon, Aug 31, 2009 at 8:25 AM, william
ratcliff wrote:
> Hi!  I just installed matplotlib version .99 (windows vista, python25,
> 32bit) and found that
> this line was missing:
> QtGui.qApp.processEvents()
>
> Adding it sped the QT4Agg backend back to reasonable speeds--but it still
> seems a bit slow.  Otherwise, I am using the excellent Python(x,y) 2.1.14
> release for my python distribution on this machine.  Could this line be
> added back?

Unfortunately, no, that line can not be added back in. When that line
is in place, the backend attempts to process queued events before it
is finished processing the current event. It was leading to segfaults
in some cases. processEvents should not be called in the middle of
processing an event.

I tested the responsiveness of panning and zooming with and without
that call to processEvents, on Linux and windows and it looked fine.
Maybe its an issue related to a specific Qt version on windows. Things
looked fine for me with Qt-4.5/PyQt-4.5 on 64bit Vista.

Darren

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] writing plain text to multi page pdf

2009-08-31 Thread Michael Droettboom 
I've been bitten by this before, too.

The current implementation of "make.py clean" is probably a remnant of 
an earlier iteration of the doc build system that really did scatter 
files all over the place.  I made some changes a few months ago to try 
to restrict "built" files to the build and examples directories.  I can 
go ahead and fix "clean" to just be a couple of "removedirs".  But I'll 
wait a day or so just to see if anyone can think of a good reason not to.

Mike

Jouni K. Seppänen wrote:
> Jouni K. Seppänen  writes:
>
>   
>>> The current interface looks easy enough to use -- it just needs to be
>>> advertised better, eg in a FAQ ( I had to read the source to find it,
>>> which works well enough for me, but not for everyone).  If you want to
>>> write one up, I'll add it to the docs.
>>>   
>> I seem to recall that the ReST docstring of backend_pdf.PdfPages was
>> included in the documentation at some point, but it is missing now from
>> . 
>> 
>
> I added some documentation again. Here's what I think probably happened
> the previous time: I added doc/api/backend_pdf_api.rst and edited
> doc/api/index_backend_api.rst, built the documentation locally to check
> that it looks OK, then at some point ran "make.html clean" to debug some
> doc problems... which destroyed my uncommitted doc changes by running
> svn-clean.
>
> How about changing "make.html clean" to be more careful? After building
> the docs, "svn status" shows the following unversioned files:
>
> ?   build
> ?   examples
> ?   _static/matplotlibrc
> ?   _templates/gallery.html
>
> "svn status --no-ignore" adds a lot of *.pyc files in various
> subdirectories. Would removing all of these achieve the expected
> cleaning effect?
>
>   

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA


--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Bugs in Qt4 backend with the latest PyQt release

2009-08-31 Thread william ratcliff 
Let me try to upgrade to PyQt 4.5--I'm currently using 4.4.3 on vista 32
bit.  Btw. are you using python 2.6 or 2.5 (I ask because I'm still on 2.5
and am wondering if anyone has noticed any difficulties with 2.6).

Cheers,
Wiliam

On Mon, Aug 31, 2009 at 9:36 AM, Darren Dale  wrote:

> Hi William,
>
> On Mon, Aug 31, 2009 at 8:25 AM, william
> ratcliff wrote:
> > Hi!  I just installed matplotlib version .99 (windows vista, python25,
> > 32bit) and found that
> > this line was missing:
> > QtGui.qApp.processEvents()
> >
> > Adding it sped the QT4Agg backend back to reasonable speeds--but it still
> > seems a bit slow.  Otherwise, I am using the excellent Python(x,y) 2.1.14
> > release for my python distribution on this machine.  Could this line be
> > added back?
>
> Unfortunately, no, that line can not be added back in. When that line
> is in place, the backend attempts to process queued events before it
> is finished processing the current event. It was leading to segfaults
> in some cases. processEvents should not be called in the middle of
> processing an event.
>
> I tested the responsiveness of panning and zooming with and without
> that call to processEvents, on Linux and windows and it looked fine.
> Maybe its an issue related to a specific Qt version on windows. Things
> looked fine for me with Qt-4.5/PyQt-4.5 on 64bit Vista.
>
> Darren
>
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] buildbot font discrepancies

2009-08-31 Thread Michael Droettboom 
You can also turn hinting off at runtime by passing a flag to freetype.  
matplotlib currently exposes this flag in the FT2Font extension, but we 
don't really expose the option to the user.  It would be simple enough 
to make it an rcParam, though, which could then be set to "no hinting" 
by the test infrastructure just to rule out some of these moving parts.  
Of course, this doesn't rule out differences between different version 
numbers of freetype.

Another thing to look into might be some sort of fuzzy or perceptual 
diffing approach.  Freddie Witheren (our GSoC student) has been looking 
into pdiff (http://pdiff.sf.net) for testing mathtex.  I don't know what 
the current status of that is.  In general, I think I prefer the goal of 
exact determinism, but if this becomes a recurring problem down the 
road, it may be easier to just try to "gloss over" these minor font 
differences.

Mike

John Hunter wrote:
> On Sun, Aug 30, 2009 at 5:47 PM, Andrew Straw wrote:
>   
>> John Hunter wrote:
>> 
>>> On Sun, Aug 30, 2009 at 4:17 PM, John Hunter wrote:
>>>   
 According to RobK, you can reconfigure your ubuntu system to turn
 these off.  He suggests:

  To use autohinting, use the hint in this post, or just run the
 following command:

  sudo dpkg-reconfigure fontconfig-config

  then choose “autohinter”, then choose “always”, then choose “no”
 
>>> If that doesn't work, this guy has more involved instructions on how
>>> to rebuild ubuntu libfreetype and disable the bytecode patch
>>>
>>> http://ubuntuforums.org/showthread.php?t=84359
>>>   
>> OK, I disabled all Ubuntu patches to libfreetype and recompiled and
>> re-installed it. Unfortunately, I'm still getting the same failures.
>>
>> Then I additionally installed fontconfig-config and did the
>> dpkg-reconfigure fontconfig-config step, setting everything to "Never".
>> Same failures.
>>
>> These font errors make me unhappy. I think we should test some very
>> simple pure libfreetype C program outputs generated on the various
>> machines. I've just been playing with ftview, but that doesn't seem to
>> have a command-line interface to save directly to a file.
>> 
>
> Attached is "example1.c" from the freetype tutorial.  When I wrote
> ft2font, I started with this tutorial and built around it, so some of
> the core logic is the same.  A lot has been added since then,
> including a lot of stuff Michael has added to improve hinting, so we
> may not see any differences at this level.  The program outputs an
> ascii-art file to stdout, so we could start by checking the md5 on the
> output.  Since *most* of your unit tests agree with the baseline, we
> may struggle to find a difference.
>
> I compiled the example with
>
> gcc -I/Users/jdhunter/dev/include
> -I/Users/jdhunter/dev/include/freetype2 -L/Users/jdhunter/dev/lib -o
> example1 example1.c -lfreetype
>
> and ran it with
>
> ./example1 ~/mpl/lib/matplotlib/mpl-data/fonts/ttf/Vera.ttf "this is a
> test" > run.out
>
> my md5 on the output is
>
> home:~/tmp> md5 run.out
> MD5 (run.out) = 01868827436d858b4452ff03f80f7222
>
> The example and output are attached -- we could easily replace the
> example "show_image" with a binary output file that we could read into
> numpy arrays to diff or display with imshow.
>
> I'm available to skype if you want to brainstorm this.
>
> JDH
> 
>
> --
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with 
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> 
>
> ___
> Matplotlib-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA


--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Why are image coordinates rounded to integers?

2009-08-31 Thread Michael Droettboom 
I think I agree that the rounding is necessary for raster backends, but 
is in the wrong place -- it should be in the backend itself.

It's needed for Agg to prevent "gaps" between the image and axes 
rectangle.  The axes rectangle is always drawn pixel-aligned using 
"round", so if the image is drawn by truncation to integers, there will 
be small gaps for certain values.  But yes, it makes sense to *not* do 
any rounding or truncation in the vector backends.

I'll commit something for this -- on the trunk, because it feels a bit 
too pervasive for the branch.

Mike

Jouni K. Seppänen wrote:
> Hi,
>
> Mike Fitzgerald reported bug #2832896 and has been investigating its
> causes:
>
> https://sourceforge.net/tracker/?func=detail&aid=2832896&group_id=80706&atid=560720
>
> The problem is that images are not drawn at exactly the same coordinates
> as other artists, so markers drawn on top of images are slightly off in
> pdf and eps output. Apparently this can be fixed, at least to some
> degree, by removing the round(...) operations from
>
> renderer.draw_image(gc, round(l), round(b), im)
>
> in _AxesImageBase.draw and making a slightly more involved change in
> AxesImage.make_image (the details are in the bug report). I haven't had
> time to investigate what this does to other backends, but I imagine the
> rounding would be necessary for raster backends.
>
> Can someone who is more familiar with the image machinery comment on the
> matter? Do we need some kind of vector/raster indication in the backends,
> in addition to the get_image_magnification method?
>
>   

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA


--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] buildbot font discrepancies

2009-08-31 Thread Andrew Straw 
Michael Droettboom wrote:
> You can also turn hinting off at runtime by passing a flag to freetype.  
> matplotlib currently exposes this flag in the FT2Font extension, but we 
> don't really expose the option to the user.  It would be simple enough 
> to make it an rcParam, though, which could then be set to "no hinting" 
> by the test infrastructure just to rule out some of these moving parts.  
> Of course, this doesn't rule out differences between different version 
> numbers of freetype.
>   
I think that, for now, we're going have the buildslaves run the same
version of freetype and have hinting disabled at freetype compile time.
(Right now we're at freetype 2.3.5.) If you want to go ahead and add a
"disable hinting" rcParam, it may come in handy in the future, but I
don't think it's a high priority right now given that we have to ensure
freetype version and thus will probably be compiling by hand it for any
buildslave.
> Another thing to look into might be some sort of fuzzy or perceptual 
> diffing approach.  Freddie Witheren (our GSoC student) has been looking 
> into pdiff (http://pdiff.sf.net) for testing mathtex.  I don't know what 
> the current status of that is.  In general, I think I prefer the goal of 
> exact determinism, but if this becomes a recurring problem down the 
> road, it may be easier to just try to "gloss over" these minor font 
> differences.
>   
The image difference approach we're currently using doesn't search for
an exact duplication but just that the error is under some threshold. I
haven't looked at the algorithm, but the printout says "RMS error". Now
that all the tests are passing, I'm going to direct my energies to
expanding the test infrastructure, especially making it easy for other
devs to write tests.

We may have to revisit these issues if, once we get a greater diversity,
the buildslaves start failing again.

-Andrew

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Bugs in Qt4 backend with the latest PyQt release

2009-08-31 Thread Darren Dale 
I've been using 2.6. It should be fine on windows now, but I can't
attest to it since I only use windows when I have to test and make
windows installers.

On Mon, Aug 31, 2009 at 10:02 AM, william
ratcliff wrote:
> Let me try to upgrade to PyQt 4.5--I'm currently using 4.4.3 on vista 32
> bit.  Btw. are you using python 2.6 or 2.5 (I ask because I'm still on 2.5
> and am wondering if anyone has noticed any difficulties with 2.6).
>
> Cheers,
> Wiliam
>
> On Mon, Aug 31, 2009 at 9:36 AM, Darren Dale  wrote:
>>
>> Hi William,
>>
>> On Mon, Aug 31, 2009 at 8:25 AM, william
>> ratcliff wrote:
>> > Hi!  I just installed matplotlib version .99 (windows vista, python25,
>> > 32bit) and found that
>> > this line was missing:
>> > QtGui.qApp.processEvents()
>> >
>> > Adding it sped the QT4Agg backend back to reasonable speeds--but it
>> > still
>> > seems a bit slow.  Otherwise, I am using the excellent Python(x,y)
>> > 2.1.14
>> > release for my python distribution on this machine.  Could this line be
>> > added back?
>>
>> Unfortunately, no, that line can not be added back in. When that line
>> is in place, the backend attempts to process queued events before it
>> is finished processing the current event. It was leading to segfaults
>> in some cases. processEvents should not be called in the middle of
>> processing an event.
>>
>> I tested the responsiveness of panning and zooming with and without
>> that call to processEvents, on Linux and windows and it looked fine.
>> Maybe its an issue related to a specific Qt version on windows. Things
>> looked fine for me with Qt-4.5/PyQt-4.5 on 64bit Vista.
>>
>> Darren
>
>



-- 
"In our description of nature, the purpose is not to disclose the real
essence of the phenomena but only to track down, so far as it is
possible, relations between the manifold aspects of our experience" -
Niels Bohr

"It is a bad habit of physicists to take their most successful
abstractions to be real properties of our world." - N. David Mermin

"Once we have granted that any physical theory is essentially only a
model for the world of experience, we must renounce all hope of
finding anything like the correct theory ... simply because the
totality of experience is never accessible to us." - Hugh Everett III

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Bugs in Qt4 backend with the latest PyQt release

2009-08-31 Thread william ratcliff 
Ok, I upgraded to python 2.6, installed mpl 0.99 qt 4.5, and the new pyqt
and things are more responsive...However, the difference between having that
line in and taking it out are the difference between having pan/zoom events
being extremely responsive and having an extremely noticeable lag.  I've
attached a test file from the web which is rather simple.  You can notice
the lag if you either try to pan/zoom using the toolbar, or if you try to
use the slider to change the sizes of the horizontal bars.

Sigh, upgrading everything to 2.6 is going to be a chore...


Thanks,
William

On Mon, Aug 31, 2009 at 11:30 AM, Darren Dale  wrote:

> I've been using 2.6. It should be fine on windows now, but I can't
> attest to it since I only use windows when I have to test and make
> windows installers.
>
> On Mon, Aug 31, 2009 at 10:02 AM, william
> ratcliff wrote:
> > Let me try to upgrade to PyQt 4.5--I'm currently using 4.4.3 on vista 32
> > bit.  Btw. are you using python 2.6 or 2.5 (I ask because I'm still on
> 2.5
> > and am wondering if anyone has noticed any difficulties with 2.6).
> >
> > Cheers,
> > Wiliam
> >
> > On Mon, Aug 31, 2009 at 9:36 AM, Darren Dale  wrote:
> >>
> >> Hi William,
> >>
> >> On Mon, Aug 31, 2009 at 8:25 AM, william
> >> ratcliff wrote:
> >> > Hi!  I just installed matplotlib version .99 (windows vista, python25,
> >> > 32bit) and found that
> >> > this line was missing:
> >> > QtGui.qApp.processEvents()
> >> >
> >> > Adding it sped the QT4Agg backend back to reasonable speeds--but it
> >> > still
> >> > seems a bit slow.  Otherwise, I am using the excellent Python(x,y)
> >> > 2.1.14
> >> > release for my python distribution on this machine.  Could this line
> be
> >> > added back?
> >>
> >> Unfortunately, no, that line can not be added back in. When that line
> >> is in place, the backend attempts to process queued events before it
> >> is finished processing the current event. It was leading to segfaults
> >> in some cases. processEvents should not be called in the middle of
> >> processing an event.
> >>
> >> I tested the responsiveness of panning and zooming with and without
> >> that call to processEvents, on Linux and windows and it looked fine.
> >> Maybe its an issue related to a specific Qt version on windows. Things
> >> looked fine for me with Qt-4.5/PyQt-4.5 on 64bit Vista.
> >>
> >> Darren
> >
> >
>
>
>
> --
> "In our description of nature, the purpose is not to disclose the real
> essence of the phenomena but only to track down, so far as it is
> possible, relations between the manifold aspects of our experience" -
> Niels Bohr
>
> "It is a bad habit of physicists to take their most successful
> abstractions to be real properties of our world." - N. David Mermin
>
> "Once we have granted that any physical theory is essentially only a
> model for the world of experience, we must renounce all hope of
> finding anything like the correct theory ... simply because the
> totality of experience is never accessible to us." - Hugh Everett III
>
"""
This demo demonstrates how to embed a matplotlib (mpl) plot 
into a PyQt4 GUI application, including:

* Using the navigation toolbar
* Adding data to the plot
* Dynamically modifying the plot's properties
* Processing mpl events
* Saving the plot to a file from a menu

The main goal is to serve as a basis for developing rich PyQt GUI
applications featuring mpl plots (using the mpl OO API).

Eli Bendersky ([email protected])
License: this code is in the public domain
Last modified: 19.01.2009
"""
import sys, os, random
from PyQt4.QtCore import *
from PyQt4.QtGui import *

import matplotlib
from matplotlib.backends.backend_qt4agg import FigureCanvasQTAgg as FigureCanvas
from matplotlib.backends.backend_qt4agg import NavigationToolbar2QTAgg as 
NavigationToolbar
from matplotlib.figure import Figure


class AppForm(QMainWindow):
def __init__(self, parent=None):
QMainWindow.__init__(self, parent)
self.setWindowTitle('Demo: PyQt with matplotlib')

self.create_menu()
self.create_main_frame()
self.create_status_bar()

self.textbox.setText('1 2 3 4')
self.on_draw()

def save_plot(self):
file_choices = "PNG (*.png)|*.png"

path = unicode(QFileDialog.getSaveFileName(self, 
'Save file', '', 
file_choices))
if path:
self.canvas.print_figure(path, dpi=self.dpi)
self.statusBar().showMessage('Saved to %s' % path, 2000)

def on_about(self):
msg = """ A demo of using PyQt with matplotlib:

 * Use the matplotlib navigation bar
 * Add values to the text box and press Enter (or click "Draw")
 * Show or hide the grid
 * Drag the slider to modify the width of the bars
 * Save the plot to a file using the File menu
 * Click on a bar to receive an informative message
"""
QMessageBox.about(self, "About the demo"

Re: [matplotlib-devel] Bugs in Qt4 backend with the latest PyQt release

2009-08-31 Thread william ratcliff 
I should mention that the latest test was on a windows 32 bit xp box.

On Mon, Aug 31, 2009 at 11:51 AM, william ratcliff <
[email protected]> wrote:

> Ok, I upgraded to python 2.6, installed mpl 0.99 qt 4.5, and the new pyqt
> and things are more responsive...However, the difference between having that
> line in and taking it out are the difference between having pan/zoom events
> being extremely responsive and having an extremely noticeable lag.  I've
> attached a test file from the web which is rather simple.  You can notice
> the lag if you either try to pan/zoom using the toolbar, or if you try to
> use the slider to change the sizes of the horizontal bars.
>
> Sigh, upgrading everything to 2.6 is going to be a chore...
>
>
> Thanks,
> William
>
>
> On Mon, Aug 31, 2009 at 11:30 AM, Darren Dale  wrote:
>
>> I've been using 2.6. It should be fine on windows now, but I can't
>> attest to it since I only use windows when I have to test and make
>> windows installers.
>>
>> On Mon, Aug 31, 2009 at 10:02 AM, william
>> ratcliff wrote:
>> > Let me try to upgrade to PyQt 4.5--I'm currently using 4.4.3 on vista 32
>> > bit.  Btw. are you using python 2.6 or 2.5 (I ask because I'm still on
>> 2.5
>> > and am wondering if anyone has noticed any difficulties with 2.6).
>> >
>> > Cheers,
>> > Wiliam
>> >
>> > On Mon, Aug 31, 2009 at 9:36 AM, Darren Dale 
>> wrote:
>> >>
>> >> Hi William,
>> >>
>> >> On Mon, Aug 31, 2009 at 8:25 AM, william
>> >> ratcliff wrote:
>> >> > Hi!  I just installed matplotlib version .99 (windows vista,
>> python25,
>> >> > 32bit) and found that
>> >> > this line was missing:
>> >> > QtGui.qApp.processEvents()
>> >> >
>> >> > Adding it sped the QT4Agg backend back to reasonable speeds--but it
>> >> > still
>> >> > seems a bit slow.  Otherwise, I am using the excellent Python(x,y)
>> >> > 2.1.14
>> >> > release for my python distribution on this machine.  Could this line
>> be
>> >> > added back?
>> >>
>> >> Unfortunately, no, that line can not be added back in. When that line
>> >> is in place, the backend attempts to process queued events before it
>> >> is finished processing the current event. It was leading to segfaults
>> >> in some cases. processEvents should not be called in the middle of
>> >> processing an event.
>> >>
>> >> I tested the responsiveness of panning and zooming with and without
>> >> that call to processEvents, on Linux and windows and it looked fine.
>> >> Maybe its an issue related to a specific Qt version on windows. Things
>> >> looked fine for me with Qt-4.5/PyQt-4.5 on 64bit Vista.
>> >>
>> >> Darren
>> >
>> >
>>
>>
>>
>> --
>> "In our description of nature, the purpose is not to disclose the real
>> essence of the phenomena but only to track down, so far as it is
>> possible, relations between the manifold aspects of our experience" -
>> Niels Bohr
>>
>> "It is a bad habit of physicists to take their most successful
>> abstractions to be real properties of our world." - N. David Mermin
>>
>> "Once we have granted that any physical theory is essentially only a
>> model for the world of experience, we must renounce all hope of
>> finding anything like the correct theory ... simply because the
>> totality of experience is never accessible to us." - Hugh Everett III
>>
>
>
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Bugs in Qt4 backend with the latest PyQt release

2009-08-31 Thread Darren Dale 
I don't understand. With py-2.6, are things more responsive or is
there an extremely noticeable lag?

On Mon, Aug 31, 2009 at 11:51 AM, william
ratcliff wrote:
> Ok, I upgraded to python 2.6, installed mpl 0.99 qt 4.5, and the new pyqt
> and things are more responsive...However, the difference between having that
> line in and taking it out are the difference between having pan/zoom events
> being extremely responsive and having an extremely noticeable lag.  I've
> attached a test file from the web which is rather simple.  You can notice
> the lag if you either try to pan/zoom using the toolbar, or if you try to
> use the slider to change the sizes of the horizontal bars.
>
> Sigh, upgrading everything to 2.6 is going to be a chore...
>
>
> Thanks,
> William
>
> On Mon, Aug 31, 2009 at 11:30 AM, Darren Dale  wrote:
>>
>> I've been using 2.6. It should be fine on windows now, but I can't
>> attest to it since I only use windows when I have to test and make
>> windows installers.
>>
>> On Mon, Aug 31, 2009 at 10:02 AM, william
>> ratcliff wrote:
>> > Let me try to upgrade to PyQt 4.5--I'm currently using 4.4.3 on vista 32
>> > bit.  Btw. are you using python 2.6 or 2.5 (I ask because I'm still on
>> > 2.5
>> > and am wondering if anyone has noticed any difficulties with 2.6).
>> >
>> > Cheers,
>> > Wiliam
>> >
>> > On Mon, Aug 31, 2009 at 9:36 AM, Darren Dale  wrote:
>> >>
>> >> Hi William,
>> >>
>> >> On Mon, Aug 31, 2009 at 8:25 AM, william
>> >> ratcliff wrote:
>> >> > Hi!  I just installed matplotlib version .99 (windows vista,
>> >> > python25,
>> >> > 32bit) and found that
>> >> > this line was missing:
>> >> > QtGui.qApp.processEvents()
>> >> >
>> >> > Adding it sped the QT4Agg backend back to reasonable speeds--but it
>> >> > still
>> >> > seems a bit slow.  Otherwise, I am using the excellent Python(x,y)
>> >> > 2.1.14
>> >> > release for my python distribution on this machine.  Could this line
>> >> > be
>> >> > added back?
>> >>
>> >> Unfortunately, no, that line can not be added back in. When that line
>> >> is in place, the backend attempts to process queued events before it
>> >> is finished processing the current event. It was leading to segfaults
>> >> in some cases. processEvents should not be called in the middle of
>> >> processing an event.
>> >>
>> >> I tested the responsiveness of panning and zooming with and without
>> >> that call to processEvents, on Linux and windows and it looked fine.
>> >> Maybe its an issue related to a specific Qt version on windows. Things
>> >> looked fine for me with Qt-4.5/PyQt-4.5 on 64bit Vista.
>> >>
>> >> Darren
>> >
>> >
>>
>>
>>
>> --
>> "In our description of nature, the purpose is not to disclose the real
>> essence of the phenomena but only to track down, so far as it is
>> possible, relations between the manifold aspects of our experience" -
>> Niels Bohr
>>
>> "It is a bad habit of physicists to take their most successful
>> abstractions to be real properties of our world." - N. David Mermin
>>
>> "Once we have granted that any physical theory is essentially only a
>> model for the world of experience, we must renounce all hope of
>> finding anything like the correct theory ... simply because the
>> totality of experience is never accessible to us." - Hugh Everett III
>
>



-- 
"In our description of nature, the purpose is not to disclose the real
essence of the phenomena but only to track down, so far as it is
possible, relations between the manifold aspects of our experience" -
Niels Bohr

"It is a bad habit of physicists to take their most successful
abstractions to be real properties of our world." - N. David Mermin

"Once we have granted that any physical theory is essentially only a
model for the world of experience, we must renounce all hope of
finding anything like the correct theory ... simply because the
totality of experience is never accessible to us." - Hugh Everett III

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Bugs in Qt4 backend with the latest PyQt release

2009-08-31 Thread william ratcliff 
Things are more responsive than with python 2.5 and with qt 4.4.3, but the
lag is still noticeable--especially compared to with the addition of the
line.

On Mon, Aug 31, 2009 at 12:05 PM, Darren Dale  wrote:

> I don't understand. With py-2.6, are things more responsive or is
> there an extremely noticeable lag?
>
> On Mon, Aug 31, 2009 at 11:51 AM, william
> ratcliff wrote:
> > Ok, I upgraded to python 2.6, installed mpl 0.99 qt 4.5, and the new pyqt
> > and things are more responsive...However, the difference between having
> that
> > line in and taking it out are the difference between having pan/zoom
> events
> > being extremely responsive and having an extremely noticeable lag.  I've
> > attached a test file from the web which is rather simple.  You can notice
> > the lag if you either try to pan/zoom using the toolbar, or if you try to
> > use the slider to change the sizes of the horizontal bars.
> >
> > Sigh, upgrading everything to 2.6 is going to be a chore...
> >
> >
> > Thanks,
> > William
> >
> > On Mon, Aug 31, 2009 at 11:30 AM, Darren Dale 
> wrote:
> >>
> >> I've been using 2.6. It should be fine on windows now, but I can't
> >> attest to it since I only use windows when I have to test and make
> >> windows installers.
> >>
> >> On Mon, Aug 31, 2009 at 10:02 AM, william
> >> ratcliff wrote:
> >> > Let me try to upgrade to PyQt 4.5--I'm currently using 4.4.3 on vista
> 32
> >> > bit.  Btw. are you using python 2.6 or 2.5 (I ask because I'm still on
> >> > 2.5
> >> > and am wondering if anyone has noticed any difficulties with 2.6).
> >> >
> >> > Cheers,
> >> > Wiliam
> >> >
> >> > On Mon, Aug 31, 2009 at 9:36 AM, Darren Dale 
> wrote:
> >> >>
> >> >> Hi William,
> >> >>
> >> >> On Mon, Aug 31, 2009 at 8:25 AM, william
> >> >> ratcliff wrote:
> >> >> > Hi!  I just installed matplotlib version .99 (windows vista,
> >> >> > python25,
> >> >> > 32bit) and found that
> >> >> > this line was missing:
> >> >> > QtGui.qApp.processEvents()
> >> >> >
> >> >> > Adding it sped the QT4Agg backend back to reasonable speeds--but it
> >> >> > still
> >> >> > seems a bit slow.  Otherwise, I am using the excellent Python(x,y)
> >> >> > 2.1.14
> >> >> > release for my python distribution on this machine.  Could this
> line
> >> >> > be
> >> >> > added back?
> >> >>
> >> >> Unfortunately, no, that line can not be added back in. When that line
> >> >> is in place, the backend attempts to process queued events before it
> >> >> is finished processing the current event. It was leading to segfaults
> >> >> in some cases. processEvents should not be called in the middle of
> >> >> processing an event.
> >> >>
> >> >> I tested the responsiveness of panning and zooming with and without
> >> >> that call to processEvents, on Linux and windows and it looked fine.
> >> >> Maybe its an issue related to a specific Qt version on windows.
> Things
> >> >> looked fine for me with Qt-4.5/PyQt-4.5 on 64bit Vista.
> >> >>
> >> >> Darren
> >> >
> >> >
> >>
> >>
> >>
> >> --
> >> "In our description of nature, the purpose is not to disclose the real
> >> essence of the phenomena but only to track down, so far as it is
> >> possible, relations between the manifold aspects of our experience" -
> >> Niels Bohr
> >>
> >> "It is a bad habit of physicists to take their most successful
> >> abstractions to be real properties of our world." - N. David Mermin
> >>
> >> "Once we have granted that any physical theory is essentially only a
> >> model for the world of experience, we must renounce all hope of
> >> finding anything like the correct theory ... simply because the
> >> totality of experience is never accessible to us." - Hugh Everett III
> >
> >
>
>
>
> --
> "In our description of nature, the purpose is not to disclose the real
> essence of the phenomena but only to track down, so far as it is
> possible, relations between the manifold aspects of our experience" -
> Niels Bohr
>
> "It is a bad habit of physicists to take their most successful
> abstractions to be real properties of our world." - N. David Mermin
>
> "Once we have granted that any physical theory is essentially only a
> model for the world of experience, we must renounce all hope of
> finding anything like the correct theory ... simply because the
> totality of experience is never accessible to us." - Hugh Everett III
>
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Merge tracking of v0_99_maint broken?

2009-08-31 Thread Ryan May 
On Sat, Aug 22, 2009 at 3:24 AM, Ryan May  wrote:

>
>
> On Sat, Aug 22, 2009 at 3:01 AM, Jouni K. Seppänen  wrote:
>
>> I fixed some doc typos on the v0_99_maint branch and was going to merge
>> the fixes to the trunk, but it didn't work:
>>
>> % svnmerge.py avail -S v0_99_maint
>> svnmerge: "v0_99_maint" is neither a valid URL, nor an unambiguous
>> substring of a repository path, nor a working directory
>> % svnmerge.py avail
>> svnmerge: multiple sources found. Explicit source argument (-S/--source)
>> required.
>> The merge sources available are:
>>  /branches/mathtex
>>  /branches/v0_91_maint
>>  /branches/v0_98_5_maint
>>
>> I'm pretty sure that this used to work. What has changed in the
>> repository?
>
>
> Same behavior here. I had been having trouble doing any merges, but never
> had tracked it down.  I guess this is related.
>

Just to follow up and put in the archives for anyone searching.  It looks
like the svnmerge.py script was updated at some point since the last time I
downloaded it (probably to keep in sync with changes in SVN itself).  I was
having problems merging today, but updating to this latest version solved
all the problems.

Just FYI.

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma
Sent from Norman, Oklahoma, United States
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] SF.net SVN: matplotlib:[7620] trunk/matplotlib/lib/matplotlib

2009-08-31 Thread Eric Firing 
[email protected] wrote:
> Revision: 7620
>   http://matplotlib.svn.sourceforge.net/matplotlib/?rev=7620&view=rev
> Author:   heeres
> Date: 2009-08-31 19:50:13 + (Mon, 31 Aug 2009)

Reinier,

Thanks!  Don't forget to make a note in CHANGELOG.

Eric

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] New GUI integration in IPython

2009-08-31 Thread Brian Granger 
Hello all,

This email is being sent out to to the lists of users+devs who regularly use
IPython's "pylab" mode or "-wthread", "-qthread", "-gthread", etc. threaded
shells.  As of today, in IPython's trunk, we have a completely new
implementation of our GUI event loop integration that dramatically improves
the stability of using the TERMINAL BASED IPython with GUI applications.
This does not affect attempts to embed IPython into GUI applications.

At this point, we need developers to begin to try out the new stuff and
adapt their projects to use the new capabilities.  Here are some things you
will get:

* Stability and robustness have been improved greatly.
* KeyboardInterrupts should work on all platforms reliably.
* No more command line flags - instead everything can be
activated/de-activated/switched at runtime.  This should allow projects like
matplotlib to enable reliable backend switching.  See the new %gui magic for
more information on this.
* We have a new developer module for working with these features
(IPython.lib.inputhook).
* Unless someone complains very loudly *and* steps up to the plate to
maintain them, the old threaded shells will be removed in the next release
of IPython.

Here are some starting points for documentation on the new features:

http://bazaar.launchpad.net/~ipython-dev/ipython/trunk/annotate/head%3A/docs/source/interactive/reference.txt#L1375
http://bazaar.launchpad.net/~ipython-dev/ipython/trunk/annotate/head%3A/IPython/lib/inputhook.py
http://bazaar.launchpad.net/~ipython-dev/ipython/trunk/annotate/head%3A/IPython/core/magic.py#L3542

Please let us know if you have questions - we are more than willing to help
you get started with all of this.

Cheers,

Brian
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel