From: Steve C. <ste...@ya...> - 2005-09-23 02:45:10
|
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 |