Hi, Is there any doc of the various bindable actions? I only found http://matplotlib.sourceforge.net/users/customizing.html, and I'm not sure all of them are in there. In particular, I'd like a simple "q" keybinding to close the window, and ideally a way to run arbitrary python code. Antoine
On Saturday, October 29, 2011, Antoine Levitt <ant...@gm...> wrote: > Hi, > > Is there any doc of the various bindable actions? I only found > http://matplotlib.sourceforge.net/users/customizing.html, and I'm not > sure all of them are in there. In particular, I'd like a simple "q" > keybinding to close the window, and ideally a way to run arbitrary > python code. > > Antoine > I don't think there is a document for the default keymaps, and there has been some talk about redoing default keybindings, because they are so hidden and varies from backend to backend. In the meantime, I would suggest checking out the "event handeling" section of the examples page. You can have a function that you attach to the "key_press_event", which takes an "event" object as an argument. That event object has the key that was pressed. You can then have an if...elif...else statement for all the keys and actions, or have a dictionary of key-action pairs. Hope that helps! Ben Root
29/10/11 19:39, Benjamin Root > I don't think there is a document for the default keymaps, and there > has been some talk about redoing default keybindings, because they are > so hidden and varies from backend to backend. > > In the meantime, I would suggest checking out the "event handeling" > section of the examples page. You can have a function that you attach > to the "key_press_event", which takes an "event" object as an > argument. That event object has the key that was pressed. You can > then have an if...elif...else statement for all the keys and actions, > or have a dictionary of key-action pairs. > > Hope that helps! > Ben Root That's pretty cool! However, I have to do it for every figure I create, there doesn't seem to be a way to tell matplotlib : "whenever a figure is created, associate this handler to this event". I think I'll just wait for the keybinding stuff to get refactored, which would definitely be a good idea (I only found out via very indirect means, and had to change backend to get them working). It seems worthwhile to have a "q" default binding to exit the plot.
On Saturday, October 29, 2011, Antoine Levitt <ant...@gm...> wrote: > 29/10/11 19:39, Benjamin Root >> I don't think there is a document for the default keymaps, and there >> has been some talk about redoing default keybindings, because they are >> so hidden and varies from backend to backend. >> >> In the meantime, I would suggest checking out the "event handeling" >> section of the examples page. You can have a function that you attach >> to the "key_press_event", which takes an "event" object as an >> argument. That event object has the key that was pressed. You can >> then have an if...elif...else statement for all the keys and actions, >> or have a dictionary of key-action pairs. >> >> Hope that helps! >> Ben Root > > That's pretty cool! However, I have to do it for every figure I create, > there doesn't seem to be a way to tell matplotlib : "whenever a figure > is created, associate this handler to this event". > > I think I'll just wait for the keybinding stuff to get refactored, which > would definitely be a good idea (I only found out via very indirect > means, and had to change backend to get them working). It seems > worthwhile to have a "q" default binding to exit the plot. > The basic event handling isn't going to be refactored. I was merely speaking of how the default keymaps are set. Yes, you will need to mpl_connect for each figure object. This is standard for any GUI control system. What you can do is make a function that produces a figure for you as well as perform any event connections for you. Ben Root
29/10/11 21:20, Benjamin Root > On Saturday, October 29, 2011, Antoine Levitt > <ant...@gm...> wrote: >> 29/10/11 19:39, Benjamin Root >>> I don't think there is a document for the default keymaps, and > there >>> has been some talk about redoing default keybindings, because they > are >>> so hidden and varies from backend to backend. >>> >>> In the meantime, I would suggest checking out the "event handeling" >>> section of the examples page. You can have a function that you > attach >>> to the "key_press_event", which takes an "event" object as an >>> argument. That event object has the key that was pressed. You can >>> then have an if...elif...else statement for all the keys and > actions, >>> or have a dictionary of key-action pairs. >>> >>> Hope that helps! >>> Ben Root >> >> That's pretty cool! However, I have to do it for every figure I > create, >> there doesn't seem to be a way to tell matplotlib : "whenever a > figure >> is created, associate this handler to this event". >> >> I think I'll just wait for the keybinding stuff to get refactored, > which >> would definitely be a good idea (I only found out via very indirect >> means, and had to change backend to get them working). It seems >> worthwhile to have a "q" default binding to exit the plot. >> > > The basic event handling isn't going to be refactored. I was merely > speaking of how the default keymaps are set. Yes, you will need to > mpl_connect for each figure object. This is standard for any GUI > control system. What you can do is make a function that produces a > figure for you as well as perform any event connections for you. > > Ben Root The problem is that I don't usually invoke figure(), I just do plot(x,y), which will presumably call figure for me. So unless there's some kind of event that's run after figure is called, I can't have a generic way of adding my bindings.
On Saturday, October 29, 2011, Antoine Levitt <ant...@gm...> wrote: > 29/10/11 21:20, Benjamin Root >> On Saturday, October 29, 2011, Antoine Levitt >> <ant...@gm...> wrote: >>> 29/10/11 19:39, Benjamin Root >>>> I don't think there is a document for the default keymaps, and >> there >>>> has been some talk about redoing default keybindings, because they >> are >>>> so hidden and varies from backend to backend. >>>> >>>> In the meantime, I would suggest checking out the "event handeling" >>>> section of the examples page. You can have a function that you >> attach >>>> to the "key_press_event", which takes an "event" object as an >>>> argument. That event object has the key that was pressed. You can >>>> then have an if...elif...else statement for all the keys and >> actions, >>>> or have a dictionary of key-action pairs. >>>> >>>> Hope that helps! >>>> Ben Root >>> >>> That's pretty cool! However, I have to do it for every figure I >> create, >>> there doesn't seem to be a way to tell matplotlib : "whenever a >> figure >>> is created, associate this handler to this event". >>> >>> I think I'll just wait for the keybinding stuff to get refactored, >> which >>> would definitely be a good idea (I only found out via very indirect >>> means, and had to change backend to get them working). It seems >>> worthwhile to have a "q" default binding to exit the plot. >>> >> >> The basic event handling isn't going to be refactored. I was merely >> speaking of how the default keymaps are set. Yes, you will need to >> mpl_connect for each figure object. This is standard for any GUI >> control system. What you can do is make a function that produces a >> figure for you as well as perform any event connections for you. >> >> Ben Root > > The problem is that I don't usually invoke figure(), I just do > plot(x,y), which will presumably call figure for me. So unless there's > some kind of event that's run after figure is called, I can't have a > generic way of adding my bindings. > Try gcf().canvas.mpl_connect(...) Before any show() calls or after any particular plotting commands. Ben Root
29/10/11 21:50, Benjamin Root > On Saturday, October 29, 2011, Antoine Levitt > <ant...@gm...> wrote: >> 29/10/11 21:20, Benjamin Root >>> On Saturday, October 29, 2011, Antoine Levitt >>> <ant...@gm...> wrote: >>>> 29/10/11 19:39, Benjamin Root >>>>> I don't think there is a document for the default keymaps, and >>> there >>>>> has been some talk about redoing default keybindings, because > they >>> are >>>>> so hidden and varies from backend to backend. >>>>> >>>>> In the meantime, I would suggest checking out the "event > handeling" >>>>> section of the examples page. You can have a function that you >>> attach >>>>> to the "key_press_event", which takes an "event" object as an >>>>> argument. That event object has the key that was pressed. You > can >>>>> then have an if...elif...else statement for all the keys and >>> actions, >>>>> or have a dictionary of key-action pairs. >>>>> >>>>> Hope that helps! >>>>> Ben Root >>>> >>>> That's pretty cool! However, I have to do it for every figure I >>> create, >>>> there doesn't seem to be a way to tell matplotlib : "whenever a >>> figure >>>> is created, associate this handler to this event". >>>> >>>> I think I'll just wait for the keybinding stuff to get refactored, >>> which >>>> would definitely be a good idea (I only found out via very > indirect >>>> means, and had to change backend to get them working). It seems >>>> worthwhile to have a "q" default binding to exit the plot. >>>> >>> >>> The basic event handling isn't going to be refactored. I was > merely >>> speaking of how the default keymaps are set. Yes, you will need to >>> mpl_connect for each figure object. This is standard for any GUI >>> control system. What you can do is make a function that produces a >>> figure for you as well as perform any event connections for you. >>> >>> Ben Root >> >> The problem is that I don't usually invoke figure(), I just do >> plot(x,y), which will presumably call figure for me. So unless > there's >> some kind of event that's run after figure is called, I can't have a >> generic way of adding my bindings. >> > > Try > > gcf().canvas.mpl_connect(...) 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.
On Sat, Oct 29, 2011 at 2:52 PM, Antoine Levitt <ant...@gm...> 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. 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. 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,
30/10/11 00:27, John Hunter > On Sat, Oct 29, 2011 at 2:52 PM, Antoine Levitt > <ant...@gm...> 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.