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 <[EMAIL PROTECTED]> 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 _______________________________________________ Sugar mailing list [email protected] http://lists.laptop.org/listinfo/sugar
