From: Jae-Joon L. <lee...@gm...> - 2008-03-10 23:09:09
Attachments:
PylabBlockingInput.py
|
Hi all, I found the recent ginput function by Gael is really cool. On the other hand, I often need to take an input from other sources (I mean, other than matplotlib itself, e.g., raw_input). I don't think running a blocking function, such as a raw_input, without freezing the figure canvas has been easy in matplotlib (especially when you're in an interactive mode). But with ginput in place now, it seems quite easy. So, I'm attaching my simple implementation of ginput-like function for an arbitrary blocking function. The code is largely based on the current ginput implementation. You can use it as >>> from PylabBlockingInput import BlockingInput >>> readinput = BlockingInput(raw_input) >>> r = readinput() The blocking function itself is run in a separate thread while the main thread updates the figure with flush_events calls. Here are a few things * I only tested this with GtkAgg backend. * I must admit that I have very little experience with thread programming, and I'm not sure how usable (or safe) this approach will be in general. * Since the blocking function is not attached to any particular figure, gcf().canvas.flush_events is run by default. I hope this is useful to others and any comments will be welcomed. Cheers, -JJ ps. I believe this is my first post in matplotlib-devel list. Thanks a lot to John and others for a great plotting package. |
From: Gael V. <gae...@no...> - 2008-03-10 23:45:42
|
On Mon, Mar 10, 2008 at 07:09:03PM -0400, Jae-Joon Lee wrote: > I often need to take an input from other sources > (I mean, other than matplotlib itself, e.g., raw_input). > I don't think running a blocking function, such as a raw_input, > without freezing the figure canvas > has been easy in matplotlib (especially when you're in an interactive mode). Hum, I am not sure what is the added value to simply spawning a thread and running the blocking function in the thread. The reason I say this is that ginput is a hack, and a fragile one. The reason behind ginput is that we want to block the call threading while not blocking the GUI event loop. Can you please detail your usecase, I am afraid I am missing something here. Cheers, Gaël |
From: Gael V. <gae...@no...> - 2008-03-10 23:46:08
|
On Mon, Mar 10, 2008 at 07:09:03PM -0400, Jae-Joon Lee wrote: > I often need to take an input from other sources > (I mean, other than matplotlib itself, e.g., raw_input). > I don't think running a blocking function, such as a raw_input, > without freezing the figure canvas > has been easy in matplotlib (especially when you're in an interactive > mode). Hum, I am not sure what is the added value to simply spawning a thread and running the blocking function in the thread. The reason I say this is that ginput is a hack, and a fragile one. The reason behind ginput is that we want to block the call threading while not blocking the GUI event loop. Can you please detail your usecase, I am afraid I am missing something here. Cheers, Gaël PS: And welcome on the matplotlib-devel list. |
From: Jae-Joon L. <lee...@gm...> - 2008-03-11 03:22:29
|
Hi Gaël, I mostly work in an interactive shell (ipython), and if I simply call a blocking function (like raw_input) from the prompt, it also blocks the event loop of the matplotlib gui backend (it happens for GtkAgg, but not for TKAgg. I'm not sure with other backends, but I thought TKAgg is a special case.) So I wanted to call a raw_input (or other blocking function) in an interactive shell without freezing the figure. Hmm, maybe I'm missing something and there has been an very easy way to do it. My understading was that the gui event loop waits (without processing gui events) until the commands entered in the prompt finish. -JJ On Mon, Mar 10, 2008 at 7:45 PM, Gael Varoquaux <gae...@no...> wrote: > On Mon, Mar 10, 2008 at 07:09:03PM -0400, Jae-Joon Lee wrote: > > > I often need to take an input from other sources > > (I mean, other than matplotlib itself, e.g., raw_input). > > I don't think running a blocking function, such as a raw_input, > > without freezing the figure canvas > > has been easy in matplotlib (especially when you're in an interactive > > mode). > > > Hum, I am not sure what is the added value to simply spawning a thread > and running the blocking function in the thread. The reason I say this is > that ginput is a hack, and a fragile one. The reason behind ginput is > that we want to block the call threading while not blocking the GUI event > loop. Can you please detail your usecase, I am afraid I am missing > something here. > > Cheers, > > Gaël > > PS: And welcome on the matplotlib-devel list. > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > |
From: Gael V. <gae...@no...> - 2008-03-17 06:49:31
|
On Mon, Mar 10, 2008 at 11:22:26PM -0400, Jae-Joon Lee wrote: > I mostly work in an interactive shell (ipython), and if I simply call > a blocking function (like raw_input) > from the prompt, it also blocks the event loop of the matplotlib gui backend > (it happens for GtkAgg, but not for TKAgg. I'm not sure with other > backends, but I thought > TKAgg is a special case.) > So I wanted to call a raw_input (or other blocking function) in an > interactive shell > without freezing the figure. > Hmm, maybe I'm missing something and there has been an very easy way to do it. > My understading was that the gui event loop waits (without processing > gui events) > until the commands entered in the prompt finish. Sorry, I got lost in dealing with urgent problems again. I can't spend too much time looking at this issue, but I would like to confirm that you do seem to have a use-case here that I cannot solve with something simpler. If other people agree, I think we should move forward with your solution. Sorry for the slow response time, Gaël |