Eric Bruning wrote:
Eric Bruning wrote:
I gave it a quick try with gtk backend. The polygon is drawn based on
clicks, but nothing gets printed. Is this expected?
That is unexpected. The callback should change the color of the
lassoed dots (from green to blue, for my default colormap) and print
the verts, the coords of the lassoed points, and the 'charge' array.
Try adding a print in do_callback. One possibility is that the trigger
on idle_event isn't working.
do_callback is not getting run.
Eric
Hello Eric -
I am interested. I wouldn't mind seeing it in mpl, but before we get there
is there a chance you may want to share the code with me? I presume it is
not long.
Hi Mark,
The code was attached to the original post. If you can't dig it out of
the archive, I'll send it personally. Let me know.
My other question is: why do you want to click a polygon? Wouldn't drawing a
rectangular box be less stress on your carpal tunnel?
My use case requires selecting from a set of points that are
distributed in a way that is unsuitable for selection with a
rectangle.
(cc'ing the mpl-dev list)
-Eric B
···
On Tue, Jul 29, 2008 at 11:12 PM, Eric Firing <efiring@...229...> wrote:
On Tue, Jul 29, 2008 at 10:53 PM, Eric Firing <efiring@...229...> wrote:
On Wed, Jul 30, 2008 at 5:40 AM, Mark Bakker <markbak@...149...> wrote:
I tried with the Tk backend, and I'm seeing the same problem as Eric F
has with GTK. The problem seems to be with idle_event not getting
triggered on some of the backends.
The checkins having to do with idle_event from the end of June
indicate that idle_event is still somewhat experimental.
What's the current status of idle_event? Can I help in some way?
If idle_event can't be made robust, I'll need to look for another
method to address the following problem. When I close off the polygon,
I determined that I needed to fall back to the idle state to be able
to see the closed polygon. My code, itself triggered off a right mouse
click, was apparently blocking drawing to the screen. It is desirable
to see the closed polygon on screen before the polygon callback in the
event that the callback takes a long time.
Thanks,
Eric
I was working on idle event, to make a backend neutral api for idle
processing, animation, etc... There was a particularly nasty problem
with tk since I had to do the threading calls myself and I am no
threading guru, so I reverted some of the changes, mainly because of
the problem of cross thread signal handling blocked the CTRL-C
interrupts. These changes were added in r5652
r5652 | jdh2358 | 2008-06-23 16:39:11 -0500 (Mon, 23 Jun 2008) | 1 line
draft idle/timeout api
and subsequent refactoring
r5653 | jdh2358 | 2008-06-23 23:17:21 -0500 (Mon, 23 Jun 2008) | 1 line
replaced idle handler with idle event
but then reverted when Nils reported the CTRL-C bug in
r5655 | jdh2358 | 2008-06-24 08:56:55 -0500 (Tue, 24 Jun 2008) | 1 line
removed idle support from tkagg until I figure out interrupts
So the implementation is incomplete and tkagg needs to most work,
since for other GUIs it is fairly easy to pass through the native
enent handling. I am not sure what the problem is with GTK right now,
and haven't had a chance to look at it.
JDH
···
On Wed, Jul 30, 2008 at 4:31 PM, Eric Bruning <eric.bruning@...149...> wrote:
I tried with the Tk backend, and I'm seeing the same problem as Eric F
has with GTK. The problem seems to be with idle_event not getting
triggered on some of the backends.
The checkins having to do with idle_event from the end of June
indicate that idle_event is still somewhat experimental.
What's the current status of idle_event? Can I help in some way?