matplotlib-devel Mailing List for matplotlib

On Sun, 2005年09月18日 at 16:45 -0400, Abraham Schneider wrote:
> Currently matplotlib already draws its widgets on the canvas, so this 
> would allow a method to instead use native widgets in place of the 
> matplotlib widgets when possible. Using native widgets has the advantage 
> of response time and having a larger library at one's disposal. Even 
> without the mapping of matplotlib->native widgets, it can be useful to 
> easily put more controls to allow the plot to be altered (e.g. playing a 
> movie, rerunning a sim, etc.) This can also be accomplished (at least 
> with GTK) by adding another toolbar, but isn't always optimal.
> 
> Is there an easy method to place widgets outside of the figure widget? 
Use the usual GTK+ widget placement methods - create a gtk.Window, add a
VBox/HBox/Table etc and place the figure widget and other widgets in the
container. This would be using the matplotlib OO interface like in
examples/embedding_in_gtk2.py
> Also, does this mean that matplotlib widgets should also not be drawn on 
> the canvas?
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?).
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 checked on the link you gave, and it appears the problem occurs when 
> scrolling is involved. Currently with how things are done, I don't think 
> this will happen.
Steve
Send instant messages to your online friends http://au.messenger.yahoo.com