On Wed, Jul 2, 2008 at 3:41 PM, Barry Wark <[EMAIL PROTECTED]> wrote: > I've written the start of a Cocoa-native backend for matplotlib and > would like to submit feedback on the code and on the possibility of > including it in the standard matplotlib distribution. The backend
Hey Barry, This is great and it is something we are interested in. I haven't had a chance to test it and will be away next week but I can give you some initial thoughts. In general, we want to pare down the number of backends but OS X is an important platform and there are certainly some advantages to doing native rendering. For us to accept a new backend, we need to meet the following criteria: - someone volunteers to support it. This is a multi-year commitment. Presumably this would be you. - feature complete - images, mathtext, rotated text, etc... It sounds like the only part you are unsure about is mathtext so perhaps Michael can advise. I don't think it will be too hard since Michael has designed this to work with unicode fonts if requested. - gui backends: toolbar support If you think these are doable, that would be great. If not, I think we can rework the backend infrastructure a bit to support external backend, eg an rc backend setting which points to a file that contains the backend implementation. This latter is worth doing in any case, so if you want to have a look at it.... > implementation is not complete (image rendering and mathtext rendering > are currently no implemented, nor are the print_* methods of the > FigureCanvas). Image rendering is trivial once I figure out how to get > the pixel data out of a matplotlib image (I just haven't investigated > the API yet). The print_* methods are also trivial (see point 1 > below). I'm not sure how to handle mathtext yet. This backend has two > major feature differences from CocoaAgg: > 2. The reason I wrote the backend was so that matplotlib could be used > seemlesslly from within a Cocoa application. Thus this backend *will > not work* without an existing NSRunLoop. It won't work from the > terminal or an IPython session. It will work from the in-progress > Cocoa frontend for IPython or from any other Cocoa application. Again > there are tradeoffs. On the positive side, figure windows are treated > like any other application window, selectable from the Window menu > etc. and matplotlib becomes a seemless part of the application. > Existing backends designed to create their own runloop (e.g. CocoaAgg > or TkAgg) cause menubar and run loop problems when used from within an > existing application. It would be possible to merge the CocoaAgg and > Cocoa backends in this regard to use the existing run loop if present. I know nothing about cocoa apps, but from the way you describe this I think there may be some confusion in how the backends should work. I will speak in terms of gtk since this is the toolkit I know best. The FigureCanvas should be a widget which is embeddable in an app (in a container or window, etc) -- the gtk figure canvas is such a widget and can be used in a gtk app and mpl knows nothing about the application or mainloop -- that part is up to the application developer. The FigureManager is basically a pylab helper class and is not meant to be used by the application developer, though I think some backends may have been designed differently (eg wx). The FigureManager creates a canvas, a toolbar and a window, and puts all the pieces together. "show" is a pylab construct that raises the active windows and starts the mainloop. So your backend *should* be designed so that it can be run from the shell, basically you need to create an application within the backend and start the mainloop with show -- this app will only be created in pylab mode on calls to new_figure_manager and show. I don't know if any of this makes sense for cocoa apps, but it is a nice feature for backends because then those of us who do not know how to build a cocoa app (and maybe don't want to learn) can still test the backend on pylab scripts and regular os x users can use your backend w/ pylab scripts. JDH ------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
