Re: [matplotlib-devel] Keybinding doc & close window
30/10/11 00:27, John Hunter > On Sat, Oct 29, 2011 at 2:52 PM, Antoine Levitt > wrote: >> Just typing f = gcf() displays a figure, which I don't want to do. I >> want to be able to put something in my ipython init file that'd set my >> bindings, without changing anything else. > > This is a reasonable request, though there are some implementation > details to sort through. For one, the rc file format is very simple, > and not amenable to putting in multil-ine functions. But you could > write something like > > keybinding.q : lambda event: plt.close(event.canvas.figure) > > Eg, when a key is pressed for which you have associated a lambda, we > could call your lambda with the event that triggered, and you can > access attributes like canvas.figure to operate on them. We could > eval your lambda in the pyplot namespace. But more sophisticated > functions would be difficult to expose given the simplicity of rc > format. I was thinking of ipython_config.py, which is full python. Then, add a hook for a function to be run whenever a figure is created. I don't know if I can access the matplotlib stuff from ipython_config.py though. I'll take a look. Just curious: what's the point of having a specific rc format, instead of just running python code and defining a few special functions to make it easier to write a config file? If you want to keep the rc format, why not add a command to run a python file? > > If you are interested in taking a crack at this Antoine, we'd be happy > to evaluate a pull request. If not, perhaps I or one of the other > developers can take a look. I'll take a look and report back. > > Note that in most windowing systems, it is fairly easy to bind a > keystroke to close a window, so you could get the effect of 'q' w/o > modifying MPL, though you might need a two keystroke binding, Defining "q" to mean "quit this window" for every window might be a little problematic. :-) There's always alt+f4, but I find it a little bothersome, "q" is much simpler. -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World™ now supports Android™ Apps for the BlackBerry® PlayBook™. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Sankey documentation missing in v1.1?
Hello, I don't think the web documentation is showing up for the new Sankey diagram class. I probably failed to hook it in somehow. Could someone please take a look? The file that would have produced the documentation is matplotlib/lib/matplotlib/sankey.py. I expected it would show up at http://matplotlib.sourceforge.net/api/sankey_api.html, but there's no such page. The Sankey demos did show up on the examples page and in the gallery. Also, the overview showed up in the "what's new" page. Thanks. Kevin -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World™ now supports Android™ Apps for the BlackBerry® PlayBook™. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Sankey documentation missing in v1.1?
On Sunday, October 30, 2011, Kevin Davies wrote: > Hello, > > I don't think the web documentation is showing up for the new Sankey diagram class. I probably failed to hook it in somehow. Could someone please take a look? > > The file that would have produced the documentation is matplotlib/lib/matplotlib/sankey.py. I expected it would show up at > http://matplotlib.sourceforge.net/api/sankey_api.html, but there's no such page. > > The Sankey demos did show up on the examples page and in the gallery. Also, the overview showed up in the "what's new" page. > > Thanks. > > Kevin > Whoops. I knew I forgot something. API docs are generated from adding a file to doc/api. I will upload a patch soon. Ben -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World™ now supports Android™ Apps for the BlackBerry® PlayBook™. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Thoughts on more loosely coupling Axes objects from Figures
I'm trying to develop some control-systems libraries and I would like to add some functionality to give plots of transfer-function representations, but I've run into a bit of a stumbling-block. For a given transfer function, I would like to give a way of constructing a an Axes object to be added into a figure. Normally, it would be just fine to send in an Axes from the user, but I need a particular (Polar) projection, which can only be specified at the Axes creation and requires suficient user knowledge to do something that should be done by the library. I could not find any way to construct my graph in a function exactly as it should be represented and then return it for the user to add it into a figure as a subplot. I could simply be going about this the wrong way, but I've dug into the sources a bit and I see from the inheritance of the Artist object that Axes is quite strongly tied into the figure that created it. It seems that Matplotlib is particularly figure-centric. Now this is great because it gives you very great tools such as sharex and sharey and many of the layout options that exist, but for library development, I think that an axes-centric approach is more useful (so that the user can decide how to layout multiple graphs representing the library objects, some of which may need particular labeling and projection settings). I wanted to see what others thought about this and some options to help this situation (and to see if others think this is a big issue at all). Changing Axes itself seems too large a task since it would break API compatibility, but perhaps there could be ways of importing already-constructed Axes into a figure. Here are some options: 1) allow the add_subplot and add_axes kwarg 'axes=' to accept any axis, which it then imports into the figure (possibly creating deep copies of the Projections and Labels and such) 2) Make new Axes-like (but non-Artist) objects for the user to use (very similar interface). These would register to figure-aware Axes (possibly many of them) and propagate plotting function calls down to the Axes. They would remember the high-level plotting calls that were used on them so that future registrations of Artist-Axes would reflect everything. this is the most invasive, yet natural solution to me, but relegates the current incarnation of Axes into being "back-end" objects. 3) Make Axes its own object and make it use draw calls that take an Artist to draw high-level plotting functions. This leaves it completely decoupled, but is likely infeasible. Please let me know what you think. If there is a clear direction on this, I'll commit some time to a fix, but I'm not so familiar with the ins and outs of the code yet. Lee -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World™ now supports Android™ Apps for the BlackBerry® PlayBook™. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
