[sugar] Recursive Signal Loop.

[Joshua N Pritikin]

On Thu, Apr 24, 2008 at 04:52:52PM -0400, Eben Eliason wrote:
> I guess so, but that sounds like a pretty terrible hack.  I guess I'd
> have to set a flag within CollapsedEntry upon the notify::keep
> callback, and then check for the state of that flag within the
> set_jobject method of the same class, skipping the update of the
> KeepIcon when true and setting it back to false. This is a roundabout
> way of getting at it, though, and it actually *depends* on the
> callback loop remaining intact in the future.

Yah, that's pretty horrible. I was think more along the lines of passing 
a "change-owner token" through the API somehow. Maybe you can't do that 
because the API doesn't offer a slot for user-data. (This might be a 
good thing to add in the shiny new olpcfs?)

Another idea, if you are certain you aren't going to use multiple 
threads, is to put the change-owner in a global variable.

> Otherwise, the flag would get set on the callback, and never unset, 
> such that the next time a change was indeed performed outside the UI, 
> it would think that it just took a "long time" for the loop to go 
> around.
> 
> On Thu, Apr 24, 2008 at 4:45 PM, Joshua N Pritikin <jpritikin at pobox.com> wrote:
> > I'm not sure if I understood the problem, but ..
> >
> >  One way to handle this is to keep track of who made the change. If the
> >  change was coming from the user then the UI is already updated and does
> >  not need to be updated. If the change is coming from the DS (not the
> >  user) then the UI does need to be updated.

-- 
Make April 15 just another day, visit http://fairtax.org