Jason Tackaberry wrote: > On Wed, 2006-04-19 at 15:29 +0200, Dirk Meyer wrote: >> gtk_idle_add is something different. BTW, we should also rename our >> idle signal to maybe step. > > Hmm, I see what you mean. > > Or possibly have both. We do need a step signal, particularly for the > canvas auto-render feature, we need to be able to render the canvas > after some callback has modified it.
Right. That is why the current pynotifier trunk supports it the same
way the generic notifier does.
> But "idle" does have its uses. When we want something to happen every
> now and then, but don't care about being guaranteed when. We could fire
> that signal if there's been no socket activity or timers going off. I
> guess we'd need to get that information somehow from notifier. It could
> be emitted from the step signal.
It should be easy to add to the generic notifier if we really need
this. It could be a simple:
| if len(idle_callbacks):
| select_timeout=0
| select(...)
| if not timer_expired and not socket_action:
| # call one callback now
| cb = idle_callbacks.pop(0)
| if cb():
| idle_callbacks.append(cb)
But while you having something in the idle callback, you will always
use 100% CPU time.
> If you want to s/idle/step/g for now, that's fine with me.
I will do between later today and next weekend.
Dischi
--
Woodward's Law:
A theory is better than its explanation.
pgpSMIsI7bTIP.pgp
Description: PGP signature
