The callback system is figure-oriented. Any GUI action that can trigger a callback can only happen to whichever figure window is currently in focus. There are no global actions that can trigger callbacks across multiple figures. The callback function will get an Event object that contains pertinent information about the fired event. In the following example, we will hook up two events to a figure: a keyboard button press and a mouse button press. There are two callback functions, each printing out some of the available pieces of information for their respective events:

Code: chp2/basic_mpl_connect.py

from __future__ import print_function 
import matplotlib.pyplot as plt 

def process_key(event): 
    print("Key:", event.key) 
def process_button(event): 
    print("Button:", event.x, event.y, event.xdata, event.ydata, event.button) 

fig, ax = plt.subplots(1, 1) 
fig.canvas.mpl_connect('key_press_event', process_key) 
fig.canvas.mpl_connect('button_press_event', process_button...

What is the purpose of interactive plotting? Why is it important for Matplotlib to provide this feature? It is important because you want to interact with your data. What you plot in the figure is a visual representation of your data, and giving it interactivity brings that data an extra step closer to the real world by providing your users the means to interact with that data in a more physically intuitive manner. It is all about data exploration.

So far, for our project, we have only developed the means to display our storm and radar data. While we could simply use these viewers and then manually edit the associated shapefile, it would not be practical. We should be able to provide users the means to interrogate their data. To do this, we will use pick_event to add the ability to select and deselect some tracks. As a simple example, we will make a track thicker when it is selected and make it thinner when it is deselected (or simply, selected again). Let's build upon the track...

Try the previous radar example again. This time, go forward a few frames and then zoom in with the zoom tool. Now go back a frame.

Go ahead, I'll wait.

Surprised? Remember that Matplotlib has its own built-in keymap. In the default keymap, the left arrow means to go back to a previous view. When we zoomed in and then pressed the left arrow key, not only did we go back a frame via our callback, but we also went back to the original view prior to zooming via Matplotlib's default keymap. The default keymap is a very important and useful feature for providing basic interactivity for most users. However, when developing your own application using Matplotlib, you might want to disable Matplotlib's keymap entirely. The following example shows how to do that while demonstrating the next important feature of the callback system: disconnecting a callback. In this example, you can now press any non-system key or combination of keys without ever triggering a built...

We can see that our application is going to grow in complexity very soon add we continue to add features. Our current manner of keymapping is probably not going to be easily maintainable as the number of actions increase. Let's take a moment to implement something better. The most essential feature of a keymap is to tie a predefined action to an arbitrary key or key combination. This seems like the perfect job for a dictionary. Furthermore, as the keymap grows, it will become important to be able to display the keymap in a helpful manner to your users. Each key/action pair will need to come with a description that can later be displayed on demand. Also, keeping in mind that our ControlSys class is likely to grow in complexity soon, let's implement this keymap feature as a separate class that ControlSys will inherit. The code is as follows:

Source: chp2/stormcell_anim_with_keymap.py

class KeymapControl:
    def __init__(self, fig):
        self.fig = fig
        # Deactivate the...