matplotlib-devel Mailing List for matplotlib

>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:
 Steve> Should matplotlib have turned itself into a widget library
 Steve> / GUI toolkit? I know that for a long time John resisted
 Steve> the temptation to add widgets to matplotlib and wanted
 Steve> matplotlib to focus on being a plotting library. I agree
 Steve> with this view and think the danger now is that matplotlib
 Steve> will become too big and bloated and harder to install (like
 Steve> 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.
 Steve> I would prefer to see a 'matplotlib-core' which is a
 Steve> minimal module that focuses purely on plotting
 Steve> graphs. Other optional modules (like 'matplotlib-toolkits',
 Steve> 'matplotlib-widgets', etc) could then extend
 Steve> '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