From: Jean-Baptiste C. <Jea...@de...> - 2004-02-03 11:46:57
|
Hi ! I am using with delight the new object_picker tools as of version 0.42b It works fine but I can not find out how to draw the legend, labels, title,= etc... Neither the ax (Subplot), nor the fig (ArtistPickerFigure) have those metho= ds. How could I access them ? Thanks Kve=F0ja Jean-Baptiste --=20 ----------------------------- Jea...@de... Department of Statistics deCODE genetics Sturlugata,8 570 2993 101 Reykjav=EDk |
From: John H. <jdh...@ac...> - 2004-02-04 02:55:31
|
>>>>> "Jean-Baptiste" == Jean-Baptiste Cazier <Jea...@de...> writes: Jean-Baptiste> Hi ! I am using with delight the new object_picker Jean-Baptiste> tools as of version 0.42b It works fine but I can Jean-Baptiste> not find out how to draw the legend, labels, title, Jean-Baptiste> etc... Neither the ax (Subplot), nor the fig Jean-Baptiste> (ArtistPickerFigure) have those methods. How could Jean-Baptiste> I access them ? First, I recommend upgrading the 0.50 series as there have been APi changes that affect the object_picker code (the examples.object_picker demo script is updated). Better to catch up sooner rather than later. Second, I don't really understand your question. If you want to "draw the legend, labels, ...", you simply call the draw method. All of these things (Legend, Text, etc..) are derived from Artist, which implements a "draw" method. so you can call legend.draw() label.draw() and so on? Then later you say "those methods" using the plural. I don't know what you mean..... Could you elaborate, and perhaps provide some code with comments showing where you are stuck? Thanks, JDH |
From: John H. <jdh...@ac...> - 2004-02-11 17:46:17
|
>>>>> "Jean-Baptiste" =3D=3D Jean-Baptiste Cazier <Jean-Baptiste.cazier@d= ecode.is> writes: Jean-Baptiste> S=E6ll ! Thanks for the info and update. I upgaded Jean-Baptiste> my library and my program. The dramatic change of Jean-Baptiste> API was a bit painful, but the new syntax is more Jean-Baptiste> clear. Do you have any idea when you will hav Jean-Baptiste> reached a stable version in general and in term of Jean-Baptiste> version ? It has been a bit painful, my apologies; I still have one application to port myself. But it was necessary. matplotlib is undergoing active development. The basic idea is to write a backend for a powerful image renderer, http://antigrain.com or libart , and use that backend to draw to the GUIs. Rather than each GUI implementing it's own drawing, I'm moving to one high quality image renderer that will draw to the GUI. Why? Four major benefits * Easier maintenance: when I want to add a feature, I add it to the image backend and all the GUIs automatically benefit. * Enhanced drawing capabilities - the GUIs don't support a lot of the more sophisticated drawing capabilities, eg, paths from PS and SVG, or alpha blending, or gouraud shading. The agg backend supports all of these, and therefore by extension, so will the GUIs. * Font standardization across backends. With a common image renderer that supports freetype, all the GUIs can have freetype support with common font names. =20 * Ease of plain old image integration with figures - 2D image plots, like pcolor, will become very fast and very pretty. Any solution along these lines will be performance competitive with native GUI and work on all major platforms (win32, osx, linux, unix) or we won't do it. In order to do this right, I needed the Figure class (and all it's children) to be totally backend independent. So a WX figure can render to a postscript renderer, or an agg renderer, or a gd renderer, or a libart renderer. In earlier releases of matplotlib, the AxisText and Figure classes were tied up in the backend. I have made it a policy not to predict a stable API because I don't want to go back on my word. That said, I think the existing design is clean and I am happy with it. I would not have said that a month ago. I don't anticipate any major changes to the Figure API or the FigureCanvas API. Changes I do expect to see in the near future are * the addition of GTK/AGG, WX/AGG and Tkinter/AGG backends. These will be optional so for those of you who want to stay with the classic GUI backends you can. But I would encourage you to move over at that time since you'll get better drawing, more sophisticated plots, etc... I will probably add a matplotlibrc file in which you can select your default backend. This will be an almost trivial API port, if you choose to. This will probably be around matplotlib-0.6 (1-2 months). * Addition of path drawing methods in the renderer API. This will allow for the more sophisticated that state dependent paths support. If you don't work directly with the renderer, it won't affect you. It's mainly for backend implementers. As for API stability in general, I have 2 additional thoughts. * for the matlab interface, if it's matlab compatible it's 99% likely to be stable. We've made minor departures from this when there was clearly a better way to do it, but it's a good rule of thumb. * As with many projects, I think the 1.0 release should guarantee some API stability. I predict you'll see a pretty stable API until then. JDH |
From: matthew a. <ma...@ca...> - 2004-02-11 23:24:13
|
Excuse me, what does AGG stand for? And I'm curious, have you looked into cairo as a possible backend? It's a vector drawing library that's trying to be OS independent. I think there's a python interface. So far it outputs to bitmap images, X11, postscript, and an Open GL port is underway. http://freedesktop.org/Cairo/Home Interested to hear your thoughts. Maybe it's a matter of a job looking for a volunteer. Cheers, Matthew. |
From: John H. <jdh...@ac...> - 2004-02-12 20:41:43
|
>>>>> "matthew" == matthew arnison <ma...@ca...> writes: matthew> Excuse me, what does AGG stand for? And I'm curious, matthew> have you looked into cairo as a possible backend? It's a matthew> vector drawing library that's trying to be OS matthew> independent. I think there's a python interface. So far matthew> it outputs to bitmap images, X11, postscript, and an Open matthew> GL port is underway. Agg is the antigrain geometry image library. It's a vector oriented C++ graphics library that is very fast and has lots of nice features. The name antigrain means that it is designed not to have pixel granularity, aka aliasing, in drawing. It achieves this with1 pixel blending algorithms from computational geometry. http://antigrain.com It's also the rendering library used by chaco. matthew> http://freedesktop.org/Cairo/Home Many moons ago, a cairo backend was suggested -- also by an Australian :-). At that time, the consensus was perhaps it made more sense to do an SVG backend - which you could then feed to cairo. matthew> Interested to hear your thoughts. Maybe it's a matter of matthew> a job looking for a volunteer. Are you considering it? Actually, an svg (or cairo) backend would not be too hard since you could follow the paint backend. paint/libart is modeled after SVG, so it provides a good template. JDH |