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.
PylabBlockingInput.py (1.53 KB)
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
···
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.
···
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).
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 <gael.varoquaux@...427...> 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
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options
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
···
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.