On Thu, Jul 3, 2008 at 8:41 AM, John Hunter <[EMAIL PROTECTED]> wrote:
> 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.
Yes.
>
> - 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.
Using unicode fonts should make it easy.
>
> - gui backends: toolbar support
Currently not implemented, but not a problem.
>
> 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....
This would be _very_ useful, whether or not you decide to include a
Cocoa native backend in the distribution. Perhaps also making it
possible to delegate to an other package instead of just a file so
that backends could be installed as separate eggs would be useuful
(e.g. delegate the backend to my.package.backend).
>
>> 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.
No, in fact you've done a very good job of communicating the
architecture and it appears that it was my mistake in explaining my
work that's led to confusion. backend_cocoa.FigureCanvasView (a
FigureCanvas subclass) is an NSView subclass that can be embedded in a
Cocoa application to render matplotlib figures.
We have a special use case in mind for the
backend_cocoa.FigureManagerCocoa (the FigureManager subclass),
however. I'm not sure if you've been following discussions on the
ipython-dev regarding GUI frontends for IPython, so let me briefly
recap. The new Twisted-based architecture of IPython now allows easy
development of GUI frontends for the IPython engine because the engine
is decoupled from readline. Thus a Cocoa-based frontend for IPython
might behave like a terminal but be implemented as a native Cocoa
widget that can be embedded in other applications. We want the user of
this GUI IPython frontend to be able to use matplotlib as if in a
pylab session at the terminal. Because there's already an NSRunLoop
running, however, the existing backends that attempt to start their on
run loop cause problems. I imagine GUI frontends (on OS X) doing a
matplotlib.use('Cocoa') at startup but the user keeping their existing
backend for terminal usage. I haven't yet explored the
FigureManagerCocoa creating its own runloop if none exists. If you
want to try the new IPython frontend (still very much a work in
progress), have a look in the IPython/frontend/cocoa/examples
directory of IPython trunk (launchpad.net/ipython).
Thus there are really two different aspects to consider for backend_cocoa
1. Native rendering. this may or may not be valuable. If valuable, we
could merge this renderer into the existing CocoaAgg backend,
replacing the FiureCanvas that blits from the Agg renderer.
2. A FigureManager for use *within* a running cocoa application. I
will investigate using the FigureManagerCocoa from terminal as well,
but that's not the use case I wrote it for.
Although I personally think (2) (in conjunciton with a native forntend
for IPython) is the way of the future on OS X, it may still be too
small a use case for you to feel its inclusion in matplotlib is
valuable. In that case, being able to delegate the backend to an other
package as discussed above would meet our needs.
>
> 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.
backend_cocoaagg already does this. if there's a compelling reason to
move to the native renderer, we could merge that into
backend_cocoaagg. backend_cocoa provides a separate functionality --
simulating a pylab session from within a native GUI frontend for
IPython.
>
> 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
