On Fri, 2004-04-16 at 08:09, John Hunter wrote:
> I think now is a good time to start implementing some GUI neutral
> event handling and wanted to bounce some ideas off the list. The idea
> is for matplotlib to define its own event handler in matplotlib.events
> and each of the GUIs trigger these events. Users could register with
> the event handler using an observer pattern. In user space, you could
> do something like the following and expect it to work across Tk, Wx
> and GTK::
> import matplotlib.events as events
> def key_press(event):
> print event.key
> events.connect('key_press', key_press)
> def button_press_press(event):
> print event.button
> events.connect('button_press', button_press)
> Each of the GUIs would call matplotlib.events.notify. The backends
> would have to map the GUI constants, eg LEFT_BUTTON, to the
> appropriate matplotlib.event constant and handle things like flip y
> inversion since the matplotlib coordinate system is 0,0 = lower, left.
> This would also lay the groundwork for generalizing things like
> examples/object_picker.py, writing generic measure tools, and so on.
> You could write a GUI neutral axes resize tool where the user could
> click on an axes and drag the size. So it would be useful for the
> users who want to define some GUI interaction and or the developers
> who want to add features across backends w/o having to know all the
> widget sets.
> My questions are
> * Does this look like a good framework?
The meaning of the coords_demo_gtk was clear and easy to emulate. The
meaning of the events interface above (in the context of multiple figure
managers) is not so clear.
> * Does someone want to implement the interface matplotlib.events?
> * Do the GUI maintainers for Tk (Todd), Wx (Jeremy) and GTK (Me)
> have time to do the mapping? If not can we get another volunteer?
I'm not imagining this as a major time sink so I'm pretty sure I'll be
able to support this.
> * What events do we want to define? The ones I use a lot are::
> If these basic events are implemented at the backend level, we
> could catch them and trigger more complicated events like
> 'drag_rectangle' in matplotlib.events. Ie, catch press, mouse
> move, and release, and then trigger drag_rectangle with start and
> end locations in event.start and event.end.
> * There is the issue of coords. x, y can be given in data, axes
> (0-1) or data coords. Probably best to give all three
> event.xdata, event.ydata,
> event.xaxis, event.yaxis,
> event.xdisplay, event.ydisplay
> See examples/coords_demo_gtk.py for an example of connecting to a
> GTK event and mapping the display coords to data space. Jeremy
> and Todd, this would be a good example to implement as stage 1 for
> the event handling.
I implemented the coords demo for TkAgg this morning (just replace GTK
with TkAgg in the demo). I did this by implementing connect() for
FigureCanvasTkAgg... very simple so far.
> Of course, there is no end to how far you could go with this, defining
> a basic cross GUI widget API for dialog boxes, entry boxes and so on.
> A meta-wx, if you will. But that is an issue for another day.
I can see the utility of GUI neutrality and I'm in favor of it, but I'm
also inclined to keep it as simple as possible. I think it would be
easy to go overboard and start worrying about creating a meta-GUI
instead of a plotter. If we drive the backend development with demos
and concrete applications (rather than some abstract idea of universal
GUI substitutability) I think the idea will turn out well.
Todd Miller <jmiller@...>