Hi, I have written a basic QtAgg backend for Matplot-lib. It is only tested on Windows, so some more testing should be done, but it is my hope that it can some day be included in the matplotlib distribution. I will test on linux when I get the time, but all the code is python so it should probably work ok. See http://www.tjora.no/python/matplotlib/ for the code. Most examples run ok, but the keypress_demo.py does not work yet. Not all examples have been tested, just some random double-clicking on the one that look interesting. A lot of the comments from the backend_template.py has not been removed or fixed. The code is also somewhat rough around the edges, but it works. Is there any unittest-suite it is possible to run the backend against? Feedback is welcome. Best regards, Sigve Tjora
On Fri, 2005年01月28日 at 21:36 +0100, Sigve Tjora wrote: > Hi, > I have written a basic QtAgg backend for Matplot-lib. It is only tested > on Windows, so some more testing should be done, but it is my hope that > it can some day be included in the matplotlib distribution. I will test > on linux when I get the time, but all the code is python so it should > probably work ok. Well done. I tried it out on Linux (Fedora 3) and it works reasonably well. I noticed a few things: It puts the toolbar at the top rather than the bottom of the window. The graph is smaller and the colours are different than that produced with GTKAgg, which is strange since they both use Agg rendering. I think it would be better to have a 'backend_qt.py' file used as a base class (with a FigureCanvasQtAgg.draw() method that raises NotImplementedError), and with backend_qtagg.py overriding just those functions/methods which are specific to drawing using Agg. This would allow backend_qt.py code to be used to produce a QtCairo backend at a later date. I copied the file into cvs so other people can try it out. Regards Steve
Steve Chaplin skrev:
>Well done. I tried it out on Linux (Fedora 3) and it works reasonably
>well.
>
>
>
Thats nice.
>I noticed a few things:
>It puts the toolbar at the top rather than the bottom of the window.
>
>
Fix by changing in NavigationToolbar2QtAgg.__init:
qt.QToolBar.__init__(self, qt.QString(""), window, qt.Qt.DockTop)
to
qt.QToolBar.__init__(self, qt.QString(""), window, qt.Qt.DockBottom)
>The graph is smaller and the colours are different than that produced
>with GTKAgg, which is strange since they both use Agg rendering.
>
>
Colors are fixed in CVS, i think.
>I think it would be better to have a 'backend_qt.py' file used as a base
>class (with a FigureCanvasQtAgg.draw() method that raises
>NotImplementedError), and with backend_qtagg.py overriding just those
>functions/methods which are specific to drawing using Agg. This would
>allow backend_qt.py code to be used to produce a QtCairo backend at a
>later date.
>
>
>
I agree, but have not time to do it right now.
Regards,
Sigve
>>>>> "Sigve" == Sigve Tjora <pu...@tj...> writes: Sigve> Hi, I have written a basic QtAgg backend for Sigve> Matplot-lib. It is only tested on Windows, so some more Sigve> testing should be done, but it is my hope that it can some Sigve> day be included in the matplotlib distribution. I will test Sigve> on linux when I get the time, but all the code is python so Sigve> it should probably work ok. Indeed -- it's a testament to QT and python that the untested code appears to run the same on linux (per Steve's report) and OS X, which I tested today. Good work! Sigve> See http://www.tjora.no/python/matplotlib/ for the code. Sigve> Most examples run ok, but the keypress_demo.py does not Sigve> work yet. Not all examples have been tested, just some Sigve> random double-clicking on the one that look interesting. I think the problem here was that you had def keyPressEvent(self, ev): self.keyPressEvent(ev.text()) def keyReleaseEvent(self, ev): self.keyReleaseEvent(ev.text()) where you meant def keyPressEvent(self, ev): self.key_press_event(ev.text()) def keyReleaseEvent(self, ev): self.key_release_event(ev.text()) I made these changes in CVS, and the keypress_demo indeed works. Sigve> A lot of the comments from the backend_template.py has not Sigve> been removed or fixed. The code is also somewhat rough Sigve> around the edges, but it works. Sigve> Is there any unittest-suite it is possible to run the Sigve> backend against? The standard test suite is examples/backend_driver. You just need to set the "backends" list to the list of backends you want to test. Eg backends = ['QtAgg'] Sigve> Feedback is welcome. I agree with most of the comments Steve made. * I think factoring the class into a module that handles the qt widgets, and have a small module that does qtagg would be a good thing. Steve would likely do a qtcairo backend if you did this... * The only explanation I can think of for why the colors are wrong is that qt has a different byte order for images than you are getting from agg (is could it be bgra instead of rgba, or that something is wrong with the endianess...) If you need a different byte ordering /pixel format, I can provide the required method in the agg backend. I note that the saved figures *do* have the right color scheme, which supports this idea. * The control key modifier is apparently not recognized -- this provides aspect ratio preserving zoom. I can't test any of the right click drag functionality right now, actually, since I'm on a mac w/o an external mouse plugged in **&$$ macs! Thanks! JDH
>>>>> "John" == John Hunter <jdh...@ac...> writes: John> * The only explanation I can think of for why the colors John> are wrong is that qt has a different byte order for images John> than you are getting from agg (is could it be bgra instead John> of rgba, or that something is wrong with the endianess...) John> If you need a different byte ordering /pixel format, I can John> provide the required method in the agg backend. I note that John> the saved figures *do* have the right color scheme, which John> supports this idea. Another clue that endianess is playing a role here is that the colors are dramatically different on OSX (which I tested yesterday) ans linux which I tested today. But I think it's more than an endian problem, because the colors are wrong on both platforms. On linux, it looks like the endianess is right, but it's an rgb versus bgr thing, since the colors are backwards on from pylab import * subplot(211) plot([1,2,3], color='red') subplot(212) plot([1,2,3], color='blue') show() On OSX, it looks like the endianess is wrong because the colors are really off... Also, I took a quick at the qimage class docs at http://doc.trolltech.com/3.3/qimage.html and saw It is one of the two classes Qt provides for dealing with images, the other being QPixmap. QImage is designed and optimized for I/O and for direct pixel access/manipulation. QPixmap is designed and optimized for drawing. There are (slow) functions to convert between QImage and QPixmap: QPixmap::convertToImage() and QPixmap::convertFromImage(). Does this suggest that QPixmap might be more appropriate / faster since you don't need to do the individual pixel manipulation provided by QImage (spoken as a total qt newbie, so please forgive any stupidities on my part...) An unrelated observation regarding event handling: the qt backend is not connecting to mouse motion unless a pan/zoom button is pressed and released, eg coords_demo.py does not work properly. Cheers! JDH
We've also been working on a Qt front end. It's been going slow because we've only been able to spend about 1 oerson-day per week on it. But, starting this week I have someone full time on it. He's gotten a basic widget working using the same organization that the GTK code uses. Sigve's code has a lot more functionality in the tool bars than ours right now. Here's where we're at: - Finished C++ routine to convert AGG -> QPixmap (in /src/_qtagg.cpp) - Finished low level widget to display the AGG pixmap using a widget derived from QLabel (in ./lib/matplotlib/backends/backend_qtagg.py) - Working on a higher level window widget to display the plot and the tool bar. We implemented the tool bar as a Qt tool bar which allows you drag it around, detach it, etc. The guy working on it doesn't think it would take more than a day or two to incorporate Sigve's code for the tool bar handling into our code. We're close enough to finishing that it probably doesn't make a lot of sense to try and set up a collaboration right now but I'm open to that possibility if that's what people want. All I really interested in is seeing the QtAgg front end in matplotlib as a supported component (which we'd be happy to help maintain) so whatever gets us there the quickest sounds good to me. Ted PS: here's the code we used to do the AGG->QPixmap conversion. It may not be the fastest way to do it but it does work which is all we were after for the first cut. PyQObject* pyDrawable = static_cast< PyQObject* >( args[0].ptr() ); QLabel* label = static_cast< QLabel* >( pyDrawable->obj ); RendererAgg* aggRenderer = static_cast< RendererAgg* >( args[1].ptr() ); unsigned int width = aggRenderer->get_width(); unsigned int height = aggRenderer->get_height(); QImage image( aggRenderer->pixBuffer, width, height, 32, 0, 256, QImage::LittleEndian ); QPixmap pixmap; pixmap.convertFromImage( image, QPixmap::Color ); label->setPixmap( pixmap ); At 07:25 AM 1/31/2005, John Hunter wrote: > >>>>> "John" == John Hunter <jdh...@ac...> writes: > > John> * The only explanation I can think of for why the colors > John> are wrong is that qt has a different byte order for images > John> than you are getting from agg (is could it be bgra instead > John> of rgba, or that something is wrong with the endianess...) > John> If you need a different byte ordering /pixel format, I can > John> provide the required method in the agg backend. I note that > John> the saved figures *do* have the right color scheme, which > John> supports this idea. > >Another clue that endianess is playing a role here is that the colors >are dramatically different on OSX (which I tested yesterday) ans linux >which I tested today. But I think it's more than an endian problem, >because the colors are wrong on both platforms. On linux, it looks >like the endianess is right, but it's an rgb versus bgr thing, since >the colors are backwards on > > from pylab import * > subplot(211) > plot([1,2,3], color='red') > > subplot(212) > plot([1,2,3], color='blue') > > show() > >On OSX, it looks like the endianess is wrong because the colors are >really off... > >Also, I took a quick at the qimage class docs at >http://doc.trolltech.com/3.3/qimage.html and saw > > It is one of the two classes Qt provides for dealing with images, the > other being QPixmap. QImage is designed and optimized for I/O and for > direct pixel access/manipulation. QPixmap is designed and optimized > for drawing. There are (slow) functions to convert between QImage and > QPixmap: QPixmap::convertToImage() and QPixmap::convertFromImage(). > >Does this suggest that QPixmap might be more appropriate / faster >since you don't need to do the individual pixel manipulation provided >by QImage (spoken as a total qt newbie, so please forgive any >stupidities on my part...) > > >An unrelated observation regarding event handling: the qt backend is >not connecting to mouse motion unless a pan/zoom button is pressed and >released, eg coords_demo.py does not work properly. > >Cheers! >JDH > > >------------------------------------------------------- >This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting >Tool for open source databases. Create drag-&-drop reports. Save time >by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. >Download a FREE copy at http://www.intelliview.com/go/osdn_nl >_______________________________________________ >Matplotlib-devel mailing list >Mat...@li... >https://lists.sourceforge.net/lists/listinfo/matplotlib-devel Ted Drain Jet Propulsion Laboratory ted...@jp...
>>>>> "Ted" == Ted Drain <ted...@jp...> writes: Ted> We've also been working on a Qt front end. It's been going Ted> slow because we've only been able to spend about 1 oerson-day Ted> per week on it. But, starting this week I have someone full Ted> time on it. He's gotten a basic widget working using the Ted> same organization that the GTK code uses. Sigve's code has a Ted> lot more functionality in the tool bars than ours right now. Great -- it looks like there will be a good opportunity to merge the best features from both backends -- two functional qt backends is definitely an improvement over what we had a week ago! Particularly useful might be to retain the current implementation which uses string methods to transfer the agg image to the qt canvas as a fallback for your extension code method. That way, people who have trouble getting the extension code version working can always fallback to something slower that still works. Ted> The guy working on it doesn't think it would take more than a Ted> day or two to incorporate Sigve's code for the tool bar Ted> handling into our code. We're close enough to finishing that Ted> it probably doesn't make a lot of sense to try and set up a Ted> collaboration right now but I'm open to that possibility if Ted> that's what people want. All I really interested in is Ted> seeing the QtAgg front end in matplotlib as a supported Ted> component (which we'd be happy to help maintain) so whatever Ted> gets us there the quickest sounds good to me. Whatever works for you and Sigve works for me. My guess is that it will be easy to cross-pollinate from one implementation to the other. Thanks! JDH
Hi again Ted, As far as I can tell, we are using the same method to connect between Agg and Qt. You are doing it from C++, while I am doing it with python only. Another difference is that I subclass QWidget instead of QLabel. Can you please elaborate on why have you choosen QLabel over QWidget? I don’t see what QLabel gives you that you don’t have in QWidget. Perhaps you get double buffering? I am just curious and trying to learn... I don’t think there should be any major speed penalties by doing it all from python, but I haven’t benchmarked anything yet. Please do incorporate whatever you need from my code into your version. I am not the right person to decide what should go into Matplotlib, any solution is fine by me. I am in the same position as you; I just want a Qt-backend for Matplotlib. Good luck! Best regards, Sigve I Ted Drain skrev: > We've also been working on a Qt front end. It's been going slow > because we've only been able to spend about 1 oerson-day per week on > it. But, starting this week I have someone full time on it. He's > gotten a basic widget working using the same organization that the GTK > code uses. Sigve's code has a lot more functionality in the tool bars > than ours right now. > > Here's where we're at: > - Finished C++ routine to convert AGG -> QPixmap (in /src/_qtagg.cpp) > - Finished low level widget to display the AGG pixmap using a widget > derived from QLabel (in ./lib/matplotlib/backends/backend_qtagg.py) > - Working on a higher level window widget to display the plot and the > tool bar. We implemented the tool bar as a Qt tool bar which allows > you drag it around, detach it, etc. > > The guy working on it doesn't think it would take more than a day or > two to incorporate Sigve's code for the tool bar handling into our > code. We're close enough to finishing that it probably doesn't make a > lot of sense to try and set up a collaboration right now but I'm open > to that possibility if that's what people want. All I really > interested in is seeing the QtAgg front end in matplotlib as a > supported component (which we'd be happy to help maintain) so whatever > gets us there the quickest sounds good to me. > > Ted > > PS: here's the code we used to do the AGG->QPixmap conversion. It may > not be the fastest way to do it but it does work which is all we were > after for the first cut. > > PyQObject* pyDrawable = static_cast< PyQObject* >( args[0].ptr() ); > QLabel* label = static_cast< QLabel* >( pyDrawable->obj ); > > RendererAgg* aggRenderer = static_cast< RendererAgg* >( args[1].ptr() ); > > unsigned int width = aggRenderer->get_width(); > unsigned int height = aggRenderer->get_height(); > > QImage image( aggRenderer->pixBuffer, width, height, 32, 0, 256, > QImage::LittleEndian ); > QPixmap pixmap; > pixmap.convertFromImage( image, QPixmap::Color ); > > label->setPixmap( pixmap );
>>>>> "Sigve" == Sigve Tjora <si...@tj...> writes: Ted> All I really interested in is seeing the QtAgg front end in Ted> matplotlib as a supported component (which we'd be happy to Ted> help maintain) so whatever gets us there the quickest sounds Ted> good to me. Sigve> I am in the same position as you; I just want a Qt-backend Sigve> for Matplotlib. Well, actually it looks like Ted wants a front end and Sigve wants a backend. Let's hope these differences are not irreconcilable! <wink> JDH
John, I have someone fixing the last items (status bar and error handling) from the Qt backend and I had a few questions. You said: > * If you try to save to an unsupported output type (eg pdf) the > entire window closes -- a bit extreme This seems to happen on the TkAgg backend as well. The culprit seems to be this code (backend_tkagg.py): try: self.canvas.print_figure(fname) except IOError, msg: err = '\n'.join(map(str, msg)) msg = 'Failed to save %s: Error msg was\n\n%s' % ( fname, err) error_msg_tkpaint(msg) The exception (at least for trying to save a pdf file) is not an IOError so the message get's propagated up and you exit the event loop (which is what causes the window to disappear). I think the problem is that backend_agg.py is calling error_msg() that it COPYS from backend_bases.py. The default action from backend_bases.py is to print a message and call sys.exit() which is what is generating this message. I assume that somewhere you're trapping the exit call to send an exception? On the surface (i.e. w/o knowing the design decisions that were made), this seems like a bad idea. It seems like exceptions should be used and that sys.exit() should exit the program. Changing the behavior of a standard call like sys.exit() (if that's what is really happening) seems like a bad idea since it changes global behavior. Also, I'm a little confused about the backends use of the 'error_msg' function. Many of the backends import this function from backend_bases but then change that names definition to a local copy (see backend_gtk, backend_template, backend_wx). This seems wrong or at least more confusing that it needs to be. I don't think a script should explicitly import something with one name and then change the name to point to a local variable. Is the idea that the backends should overload the error_msg function that all the code uses? If that's the case it would be a simple change to do something like this: import backend_bases backend_bases.error_msg = error_msg_tkpaint Ted Ted Drain Jet Propulsion Laboratory ted...@jp...
>>>>> "Ted" == Ted Drain <ted...@jp...> writes: Ted> Also, I'm a little confused about the backends use of the Ted> 'error_msg' function. Many of the backends import this Ted> function from backend_bases but then change that names Ted> definition to a local copy (see backend_gtk, Ted> backend_template, backend_wx). This seems wrong or at least Ted> more confusing that it needs to be. I don't think a script Ted> should explicitly import something with one name and then Ted> change the name to point to a local variable. We're a little confused too :-) The error_msg function was initially designed to provide a way to get error messages up to the GUI, otherwise they might disappear into stderr, stdout. However, the framework has caused nothing but grief and confusion and needs to die. It has lived this long simply because noone has found the time to kill it. The system exit in the default error message function was meant to be used by image backends with the reasoning that if you get an error on an image backend, there is no point in trying to continue. But now I see the unintended consequences of this decision when we mix image and gui backends, as in qt agg. There have been prolonged discussions on the topic before. See for example the "propagation of errors thread at CVS http://sourceforge.net/mailarchive/forum.php?forum_id=36187&max_rows=100&style=threaded&viewmonth=200411 where we almost reach a consensus and then promptly repress the subject for a few more months. Last time we left off, I think I suggested that we should kill error message and use exception hooks to get the exceptions into the GUI. Steve tried to implement something like this for GTK -- I can't remember what the final result was. I think a good place to start would be to remove all instances of error_msg* from the mpl front end and backend code, and then see where we are. Any major problems with that? JDH
OK - I think I've read most of those messages and had a few comments/ideas. Soapbox mode on: Please don't change the system exception hook. Matplotlib (MPL) is not an application, it's a library. Libraries should never change global behavior - only applications. By changing global behavior you severely limit how and where your library can be used by others. Soapbox mode off. I wonder if it helps to think about errors from a different stand point. For example, I can think of two high level views that might help. Users interact with MPL either through the Python command line (via typing or scripts) or through GUI front ends. 1) A python function is called which has an error (or something it calls has an error, etc, etc). In this case, if the function throws an exception, python will propagate the exception normally. If you're typing something on the prompt or running a script, the exception get's printed with a trace back. Very useful and very normal for Python. 2) A GUI widget calls a function which has an error. If the function throws an exception, the GUI should trap that exception and show a dialog or whatever is appropriate for that GUI. So I guess I'm wondering what happens if we just throw standard Python exceptions for all errors? From the Python interface you get normal Python behavior regardless of the front end (Tk,Qt,Gtk,Agg,etc). If you executed some operation from the front end (like clicking the save file dialog in the toolbar), you get a GUI error message like any normal GUI. Is this too simple of a view? As an aside, we've found that using error stack classes work very well in exception error handling. Most of our code throws an error stack class which holds an array of error messages. This way you can trap errors and add an error message with context information at various levels. Many times errors happen at the lowest levels and you don't really know why that function was called. As a completely contrived example (and probably stupid), let's say you were saving a plot to an image and the plot had to resize/re-render to get to the right image format. You might get an error back that looks like this: - Error trying to save the plot to the image file 'plot.png'. - Error in the automatic plot layout algorithm. - Error in setting the size of the plot region. The inputs size of [-10, 200] is invalid. I realize this example doesn't make a lot of sense but hopefully it gives you some idea what you can do. In this case the lowest level function which sets the size of the region decided that the inputs were invalid. If you just propagate that error to the user, they may not have any idea why that function was called in the first place. So the higher level functions do a try...except loop where they add context messages to the error and then re-throw it. This has really helped our users get useful error messages when something goes wrong at the lowest level. I don't know if that makes any sense or would help with error reporting in MPL so feel free to ignore it completely. It was just something that has helped us a lot in using exceptions to provide useful messages to people. Ted At 11:16 AM 2/14/2005, John Hunter wrote: > >>>>> "Ted" == Ted Drain <ted...@jp...> writes: > > Ted> Also, I'm a little confused about the backends use of the > Ted> 'error_msg' function. Many of the backends import this > Ted> function from backend_bases but then change that names > Ted> definition to a local copy (see backend_gtk, > Ted> backend_template, backend_wx). This seems wrong or at least > Ted> more confusing that it needs to be. I don't think a script > Ted> should explicitly import something with one name and then > Ted> change the name to point to a local variable. > >We're a little confused too :-) > >The error_msg function was initially designed to provide a way to get >error messages up to the GUI, otherwise they might disappear into >stderr, stdout. However, the framework has caused nothing but grief >and confusion and needs to die. It has lived this long simply because >noone has found the time to kill it. The system exit in the default >error message function was meant to be used by image backends with the >reasoning that if you get an error on an image backend, there is no >point in trying to continue. But now I see the unintended >consequences of this decision when we mix image and gui backends, as >in qt agg. > >There have been prolonged discussions on the topic before. See for >example the "propagation of errors thread at CVS > >http://sourceforge.net/mailarchive/forum.php?forum_id=36187&max_rows=100&style=threaded&viewmonth=200411 > > >where we almost reach a consensus and then promptly repress the >subject for a few more months. Last time we left off, I think I >suggested that we should kill error message and use exception hooks to >get the exceptions into the GUI. Steve tried to implement something >like this for GTK -- I can't remember what the final result was. > > > >I think a good place to start would be to remove all instances of >error_msg* from the mpl front end and backend code, and then see where >we are. Any major problems with that? > >JDH Ted Drain Jet Propulsion Laboratory ted...@jp...
John Hunter wrote: > John> * The only explanation I can think of for why the colors > John> are wrong is that qt has a different byte order for images > John> than you are getting from agg (is could it be bgra instead > John> of rgba, or that something is wrong with the endianess...) > John> If you need a different byte ordering /pixel format, I can > John> provide the required method in the agg backend. I note that > John> the saved figures *do* have the right color scheme, which > John> supports this idea. > >Another clue that endianess is playing a role here is that the colors >are dramatically different on OSX (which I tested yesterday) ans linux >which I tested today. But I think it's more than an endian problem, >because the colors are wrong on both platforms. On linux, it looks >like the endianess is right, but it's an rgb versus bgr thing, since >the colors are backwards on > > from pylab import * > subplot(211) > plot([1,2,3], color='red') > > subplot(212) > plot([1,2,3], color='blue') > > show() > >On OSX, it looks like the endianess is wrong because the colors are >really off... > > This was actually wrong in windows also, read and blue had switched. By using this draw, it is corrected. def draw(self): """ Draw the figure using the renderer """ FigureCanvasAgg.draw(self) self.stringBuffer = str(self.buffer_rgba()) wrongqimage = qt.QImage(self.stringBuffer, self.renderer.width, self.renderer.height, 32, None, 0, qt.QImage.IgnoreEndian) self.qimage = wrongqimage.swapRGB() self.update() That probably leaves us with the OSX problems, though. Ahh, fixed in CVS, ok then. >Also, I took a quick at the qimage class docs at >http://doc.trolltech.com/3.3/qimage.html and saw > > It is one of the two classes Qt provides for dealing with images, the > other being QPixmap. QImage is designed and optimized for I/O and for > direct pixel access/manipulation. QPixmap is designed and optimized > for drawing. There are (slow) functions to convert between QImage and > QPixmap: QPixmap::convertToImage() and QPixmap::convertFromImage(). > >Does this suggest that QPixmap might be more appropriate / faster >since you don't need to do the individual pixel manipulation provided >by QImage (spoken as a total qt newbie, so please forgive any >stupidities on my part...) > > > I think that QPixmap or better yet QCanvas would be the appropriate if you are making a pure Qt-backend, but that QImage is the choice for a backend with other rendering as Agg or Cairo. >An unrelated observation regarding event handling: the qt backend is >not connecting to mouse motion unless a pan/zoom button is pressed and >released, eg coords_demo.py does not work properly. > > > Adding this to the end of FigureCanvasQtAgg.__init__ will fix tracking: self.setMouseTracking(True) Regards, Sigve
>>>>> "Sigve" == Sigve Tjora <si...@tj...> writes: Sigve> That probably leaves us with the OSX problems, though. Ahh, Sigve> fixed in CVS, ok then. I'm lost here -- as far as I know the endianess problem *was not* fixed in CVS. I did add an agg method tostring_bgra to CVS which appears to fix the reversed color problem. I haven't had a chance to test this on OSX since my powerbook is at home... Sigve> I think that QPixmap or better yet QCanvas would be the Sigve> appropriate if you are making a pure Qt-backend, but that Sigve> QImage is the choice for a backend with other rendering as Sigve> Agg or Cairo. OK, I'll leave that to you, since I now next to nothing about qt. Sigve> Adding this to the end of FigureCanvasQtAgg.__init__ will Sigve> fix tracking: Sigve> self.setMouseTracking(True) Yep, works. Easy enough. Any thoughts about why the figure doesn't refresh during pan and zoom. On my box (linux) the update only occurs after the mouse button is released. The other annoyance vis-a-vis nav toolbar I notice is the flicker when doing the rubberbanding for zoom to rect. Any idea how to implement double buffering to avoid the flicker? Thanks! JDH
John Hunter wrote: > Sigve> That probably leaves us with the OSX problems, though. Ahh, > Sigve> fixed in CVS, ok then. > >I'm lost here -- as far as I know the endianess problem *was not* >fixed in CVS. I did add an agg method tostring_bgra to CVS which >appears to fix the reversed color problem. I haven't had a chance to >test this on OSX since my powerbook is at home... > > > Sorry about that, it came out wrong. Yes the inversed color could be fixed (I have not tested the CVS-version yet), the endiannes is not. You could try to change the endian in FigureCanvasQtAgg.draw() self.qimage = qt.QImage(self.stringBuffer, self.renderer.width, self.renderer.height, 32, None, 0, qt.QImage.IgnoreEndian, ) to self.qimage = qt.QImage(self.stringBuffer, self.renderer.width, self.renderer.height, 32, None, 0, qt.QImage.BigEndian, ) Or perhaps qt.QImage.LittleEndian if that is the way the conversion should go. Good luck! Regards, Sigve
>>>>> "Ted" == Ted Drain <ted...@jp...> writes: Ted> OK - I think I've read most of those messages and had a few Ted> comments/ideas. Soapbox mode on: Please don't change the Ted> system exception hook. Matplotlib (MPL) is not an Ted> application, it's a library. Libraries should never change Ted> global behavior - only applications. By changing global Ted> behavior you severely limit how and where your library can be Ted> used by others. Soapbox mode off. Point taken. One might view the pylab interface as an application, but I won't quibble. Ted> I wonder if it helps to think about errors from a different Ted> stand point. For example, I can think of two high level Ted> views that might help. Users interact with MPL either Ted> through the Python command line (via typing or scripts) or Ted> through GUI front ends. Ted> 1) A python function is called which has an error (or Ted> something it calls has an error, etc, etc). In this case, if Ted> the function throws an exception, python will propagate the Ted> exception normally. If you're typing something on the prompt Ted> or running a script, the exception get's printed with a trace Ted> back. Very useful and very normal for Python. There is a wrinkle here. On win32 (or another platform that binds python scripts to an executable), you might double click on a script from pylab import * semilogy([0,1,2,3]) show() In pre 0.72 mpl, this would throw an exception. On windows, if you double clicked this script, a stdout window would launch and die before you could read the traceback -- very annoying. That's the primary reason I tried to catch exceptions in the pylab interface and forward them on to the error_msg handler function. But the current impl. is admittedly broken. Do you have a suggestion for how to handle this case? We could do something like this: all GUIs define a function show_message. This pops up a message dialog with a single OK button. pylab dies the following def plot(*args, **kwargs): # allow callers to override the hold state by passing hold=True|False b = ishold() h = popd(kwargs, 'hold', None) if h is not None: hold(h) try: ret = gca().plot(*args, **kwargs) except: msg = ...get the traceback as string ... show_message(msg) hold(b) ...rethrow the same exception.... else: try: draw_if_interactive() except: msg = ...get the traceback as string... show_message(msg) hold(b) ...rethrow the same exception.... hold(b) return ret Someone please remind me how to rethrow the last exception -- Fernando? Or we could just ignore it and let win32 users who are double clicking scripts die the painful death they deserve. It would certainly make for cleaner pylab code. Ted> - Error trying to save the plot to the image file 'plot.png'. Ted> - Error in the automatic plot layout algorithm. - Error in Ted> setting the size of the plot region. The inputs size of Ted> [-10, 200] is invalid. This gives you more diagnostic information in that you get helpful messages at each level, but the standard traceback gives you all the levels, no? JDH
John Hunter wrote: > Someone please remind me how to rethrow the last exception -- > Fernando? try: foo except E: print 'I caught E, now I will raise it' raise Best, f
I like the idea of keeping pylab simpler. It's too bad there is no easy way to handle executable python code from Windows. Of course, windows users could write a small wrapper that traps exceptions, prints them, and then waits for a keypress - but that might be too much to ask. I think about it some more... I would vote for not having GUI messages being popped up from a script. A quick poll of our users also indicates that they expect script errors to be like python and appear in the script. One thing to think about is that if you dump all errors into a GUI, you limit the ability to use matplotlib in some applications. For example, we're considering writing a real-time plotting application that reads data from the network and keeps a screen updated of the current status (in this case, we want to plot real-time data read from spacecraft telemetry) for several teams to look at. This application needs to be very robust and handle errors explicitly so that it remains running at all times. It's generally going to be displayed on a monitor away from the computer for people to see. Since this is an automated system, it could end up trying to executing some plot command that is invalid (the down link data sometimes becomes corrupted for example). In this case, we want to catch the MPL exception and discard the last data packet or do some other type of data handling. If the error pops up a dialog, then my program is basically done for because there is no user to click the OK button. Could we set some type of option in the config file that would allow either behavior? Ted At 01:43 PM 2/14/2005, John Hunter wrote: > >>>>> "Ted" == Ted Drain <ted...@jp...> writes: > > Ted> OK - I think I've read most of those messages and had a few > Ted> comments/ideas. Soapbox mode on: Please don't change the > Ted> system exception hook. Matplotlib (MPL) is not an > Ted> application, it's a library. Libraries should never change > Ted> global behavior - only applications. By changing global > Ted> behavior you severely limit how and where your library can be > Ted> used by others. Soapbox mode off. > >Point taken. One might view the pylab interface as an application, >but I won't quibble. > > Ted> I wonder if it helps to think about errors from a different > Ted> stand point. For example, I can think of two high level > Ted> views that might help. Users interact with MPL either > Ted> through the Python command line (via typing or scripts) or > Ted> through GUI front ends. > > Ted> 1) A python function is called which has an error (or > Ted> something it calls has an error, etc, etc). In this case, if > Ted> the function throws an exception, python will propagate the > Ted> exception normally. If you're typing something on the prompt > Ted> or running a script, the exception get's printed with a trace > Ted> back. Very useful and very normal for Python. > >There is a wrinkle here. On win32 (or another platform that binds >python scripts to an executable), you might double click on a script > > from pylab import * > semilogy([0,1,2,3]) > show() > >In pre 0.72 mpl, this would throw an exception. On windows, if you >double clicked this script, a stdout window would launch and die >before you could read the traceback -- very annoying. That's the >primary reason I tried to catch exceptions in the pylab interface and >forward them on to the error_msg handler function. But the current >impl. is admittedly broken. Do you have a suggestion for how to >handle this case? > >We could do something like this: all GUIs define a function >show_message. This pops up a message dialog with a single OK button. >pylab dies the following > > >def plot(*args, **kwargs): > # allow callers to override the hold state by passing hold=True|False > b = ishold() > h = popd(kwargs, 'hold', None) > if h is not None: > hold(h) > try: > ret = gca().plot(*args, **kwargs) > except: > msg = ...get the traceback as string ... > show_message(msg) > hold(b) > ...rethrow the same exception.... > else: > try: draw_if_interactive() > except: > msg = ...get the traceback as string... > show_message(msg) > hold(b) > ...rethrow the same exception.... > > hold(b) > return ret > >Someone please remind me how to rethrow the last exception -- >Fernando? > >Or we could just ignore it and let win32 users who are double clicking >scripts die the painful death they deserve. It would certainly make >for cleaner pylab code. > > Ted> - Error trying to save the plot to the image file 'plot.png'. > Ted> - Error in the automatic plot layout algorithm. - Error in > Ted> setting the size of the plot region. The inputs size of > Ted> [-10, 200] is invalid. > >This gives you more diagnostic information in that you get helpful >messages at each level, but the standard traceback gives you all the >levels, no? > >JDH Ted Drain Jet Propulsion Laboratory ted...@jp...
>>>>> "Ted" == Ted Drain <ted...@jp...> writes:
Ted> I would vote for not having GUI messages being popped up from
Ted> a script. A quick poll of our users also indicates that they
Ted> expect script errors to be like python and appear in the
Ted> script.
Agreed -- what designed to ease the life of point and click windows
users has turned into a monster that is bogging us down.
Ted> Could we set some type of option in the config file that
Ted> would allow either behavior?
No, afraid not. All that crappy error handling cruft is going in the
heap. It's exceptions all the way through.
I've actually already banished every usage of error_msg from my local
tree. I think verbose.report_error should go the same way -- all
opposed, say "Nay"!
Assuming that report_error should die too, the remaining question is
how to best handle deprecation or non fatal errors
or something where we want to warn but fall back on a default
behavior. My vote is
import warnings
warnings.warn('This function is deprecated')
JDH