Gtk.Layout instead of Gtk.DrawingArea

Should matplotlib have turned itself into a widget library

    > / GUI toolkit? I know that for a long time John resisted
    > the temptation to add widgets to matplotlib and wanted
    > matplotlib to focus on being a plotting library. I agree
    > with this view and think the danger now is that matplotlib
    > will become too big and bloated and harder to install (like
    > the old SciPy?).

Hey Steve,

If I'm not mistaken, the complexity of the core matplotlib build has
not changed in quite a while -- basically we've required zlib, png,
freetype and C++ since 0.5. Yes, some backends require additional
complexity (eg GTKAgg, the new WXAgg blit functionality) but you can
simply turn these options off in setup.py if you don't need them; in
the next few weeks I'm going to try and replace _gtkagg with pure
python using python buffers. All of the changes to support blitting,
widgets and so on have either been pure python or changes to existing
extension code (eg _backend_agg.cpp and _gtkagg.cpp). Also, the size
of the widgets module, which seems to bother you, is miniscule

  > wc lib/matplotlib/widgets.py
  985 3004 32510 lib/matplotlib/widgets.py

I don't want mpl to become a widget library. I did want to add some
support for controlling the subplot parameters, a very frequent gripe.
I could have say "dear backend maintainers, please add these sliders
and buttons to make this tool" and we would still be waiting.

I don't think any of the backends other than GTK* which I added have
implemented the resize functionality I requested on Sept 14th. That
doesn't really bother me too much, because I know people are busy with
other projects, but to the extent that I can get low level
functionality that lets the frontend do these things, I and others can
can roll out functionality that benefits almost all users much more
efficiently. I implemented sliders and buttons because I needed them.
They are pure python, took me less than a day, do something useful,
work out of the box across backends, and make up a small fraction of
the total code size. Looks like a win-win to me.

I implemented other widgets as an afterthought the same day as proof
of concept, with the thought that if someone wants to make a
*matplotlib tool* if they did it using the matplotlib widgets and
events it would immediately be available to everyone. Most GUI work
in python cannot be shared because it is tk specific, wx specific and
so on, and I wanted to find a way around this problem.

    > I would prefer to see a 'matplotlib-core' which is a
    > minimal module that focuses purely on plotting
    > graphs. Other optional modules (like 'matplotlib-toolkits',
    > 'matplotlib-widgets', etc) could then extend
    > 'matplotlib-core' by providing extra features.

I think the distinction between plotting and interacting with your
plot is not so clear. Sure, some small fraction of mpl users just
generate static graphs, but the majority I would guess actually use
things like matplotlib Events regularly (ie every time they use the
pan/zoom tools). Should these be addons, or part of the core?

I'm not opposed to this kind of packaging if it were done right (eg if
everyone had something roughly equivalent to debian's apt. I think
the vast majority of users want something that "just works". Nadia
has been working on pulling all of the non-matplotlib dependencies out
of the tree (CXX, Agg, png, zlib, pytz, dateutil) and revamping the
build system to grab a tarball off the internet if a configure system
doesn't detect them. This would make matplotlib CVS and the src
distro much ligher, which I'm sure all the developers who regularly do
CVS checkouts will appreciate since the damned pytz directories take
forever. This will definitely be a step in the right direction,
especially if we can get it to work across platforms.

As far as widgets are concerned, I don' think they can be placed in
an optional toolkit because the subplot tool requires them. At under
1000 lines of pure python, I also don't see the motivation. Contrast
this with basemap, which is over 10MB with lots of extension code. Or
would you like to see the toolbar and all of it's functionality rolled
into an option addon?

JDH

Once you have a GUI independent renderer and widget like
backend_bases.RendererBase and FigureCanvasBase then you have the
building blocks for writing a large GUI independent widget toolkit.
But just because its possible does not mean you should do it. I can see
that writing a small number of widgets is useful to mpl, but am
concerned that it could easily snowball into a project that is not
directly relevant to mpl.

Abraham was suggesting that we provide a way to override these mpl
widgets and use GTK widgets instead. I think that is unnecessary and
undermines matplotlib's idea of using a GUI independent renderer and
widget.

Steve

Send instant messages to your online friends http://au.messenger.yahoo.com

···

On Tue, 2005-10-04 at 09:00 -0500, John Hunter wrote:

If I'm not mistaken, the complexity of the core matplotlib build has
not changed in quite a while -- basically we've required zlib, png,
freetype and C++ since 0.5. Yes, some backends require additional
complexity (eg GTKAgg, the new WXAgg blit functionality) but you can
simply turn these options off in setup.py if you don't need them; in
the next few weeks I'm going to try and replace _gtkagg with pure
python using python buffers. All of the changes to support blitting,
widgets and so on have either been pure python or changes to existing
extension code (eg _backend_agg.cpp and _gtkagg.cpp). Also, the size
of the widgets module, which seems to bother you, is miniscule

  > wc lib/matplotlib/widgets.py
  985 3004 32510 lib/matplotlib/widgets.py