From: John H. <jdh...@ac...> - 2005-02-24 17:03:49
|
>>>>> "Malte" == Malte Marquarding <Mal...@cs...> writes: Malte> John, When do you expect this to be implemented? Malte> I'd like to roll out a package depending on matplotlib and Malte> have a request for this specific feature. I took a look at implementing this last week and talked with Fernando Perez who did the matplotlib pylab support for ipython, we came to the conclusion, that this needs to be done at the interactive shell level. The basic problem is that although you are blocking, you need to still share cpu time with the gui thread, so that you can continue to interact with your plot and generate events. What shell and backend are you using? In the meantime, you might want to suggest this idiom to your user who is asking for a blocking event class Catcher: event = None def __call__(self, event): self.event = event plot([1,2,3]) c = Catcher() connect('button_press_event', c) # no go click on the axes print c.event.xdata, c.event.ydata # and click somewhere else print c.event.xdata, c.event.ydata So even though the call is not blocking you have ready access to the event data in as way that doesn't feel like event driven programming with callbacks. I like this approach, actually. I wonder if it would be useful to assign some new pylab module variables bp = Catcher() connect('button_press_event', bp) br = Catcher() connect('button_release_event', br) kp = Catcher() connect(key_press_event', kp) and so on. Then in the pylab interface, w/o making any connections yourself, you would always have access to the last keypress event as kp.event and so on. Do people think this would be useful for interactive work? JDH |