Re: [Matplotlib-users] Backend neutral idle event won't repeat

[Mark R. <mru...@gm...>]

On Mon, Aug 3, 2009 at 1:01 PM, Christopher Barker <Chr...@no...>wrote:

> John Hunter wrote:
> >> Wriing a GUI neutal idle event handler is not easy -- I've spent some
> >> time on it but crashed and burned on tk
>
>  >  I think
> > it would be great if we could abstract the idle handler and timeout
> > handler across the GUIs so that mpl animation would be easier, but to
> > date this has eluded me.
>
> Maybe getting away from the Idle event approach would be the way to go.
> I've done a lot of (non-MPL) wx work, including animations, and NEVER
> found a use for the idle event. For animation work in wx, using a
> wx.Timer, and often a call to wx.Yield seems to generally be the way to
> go. Perhaps this same approach could be done on the other back ends as
> well.
>
> As for idle events, I've found them to be useless because you get lots
> of them when you don't need it, and may not get them when you do. In wx
> at least, an Idle event is triggered when the event loop _becomes_
> empty. That means that when the user is moving the mouse and there is no
> mouse_move event handler, you get this huge string of idle events.
> However, if the user is doing nothing for a bit, you get one event, then
> nothing until the user does something again.
>
> I can see the appeal of an Idle event -- there are all sorts of things
> you might want to do when the app is "idle", but the reality is that
> what you really want to know is when the app is _going to be_ idle for a
> bit, and there is no way to know that (at least not without Guido's time
> machine, anyway...).
>
> I've lost track of what problems you're trying to solve with idle
> events, but maybe an abstraction of a timer system would be a more
> robust approach, for animations, anyway.
>
> -Chris
>

I think that's a fantastic idea, especially if you can go abstract and make
it work for all the backends.

I've lost track of what problems you're trying to solve with idle events,
> but maybe an abstraction of a timer system would be a more robust approach,
> for animations, anyway.
>

If you're referring to my problem, I need to read data from a serial
connection which then drives an animated graph.  Going as fast as possible
is fine but honestly, it's overkill.  Strictly using timers would work in
both situations.

-Mark