Because the idle callback always returns TRUE, the idle callback is called again and again, and CPU usage is 100%.
The idle callback doesn't do any heavy processing. Regarding this problem, doing central updating when idle is simpler than using signals to update. 2013/7/20 Jasper St. Pierre <jstpie...@mecheye.net> > Low-priority idles *are* called every time the event queue is empty. Which > could happen quite a lot when the application isn't really doing anything > else. > > I don't know why your idle is causing 100% CPU usage, though. You're not > doing any heavy processing in there, right? If you recalculate the state, > and that causes set_sensitive to be called with the same value it was > before, we won't redraw the UI or anything. > > If the idle indeed is doing heavy processing, then the only thing you can > do is to call it when a state change happens somewhere. Yes, there can be > lots of state changes, but that's what entire signal system is for. Perhaps > also look at g_object_bind_property / properties / notify::prop signals? > > > On Fri, Jul 19, 2013 at 3:45 PM, Gang Chen <gang.chen...@gmail.com> wrote: > >> Richard, >> >> The UI elements are GTK actions whose sensitivity states are related to >> the states of the application. There are many possibilities that may change >> the sensitivity. If I update UI elements whenever necessary, I need to >> write too much code doing update. I prefer writing one function that >> updates all UI elements according to the current states. And I need to call >> that function when idle. This approach is simpler and cleaner. >> >> Thanks, >> Gang >> >> >> >> 2013/7/20 richard boaz <ivor.b...@gmail.com> >> >>> let's step back one second. >>> >>> your description implies that it is not possible for your UI to be >>> directly aware of the events that require follow-on updates to the UI's >>> widgets. >>> >>> but i don't understand this. can you explain a little more how/why this >>> makes sense on a design level? what exactly happens that means the UI >>> widget states are out-of-date and need to be updated? >>> >>> ideally, your UI should be aware of any state changes requiring a widget >>> update, these being either internal or external in origin. and then once a >>> state change occurs, invoke your widget updates accordingly. >>> >>> richard >>> >>> >>> On Thu, Jul 18, 2013 at 12:11 AM, Gang Chen <gang.chen...@gmail.com>wrote: >>> >>>> Hi everyone, >>>> >>>> The background is that I need to update the sensitivity of UI elements >>>> when proper. I tried to do it in a low priority idle callback that is >>>> running forever. But that will cause 100% CPU usage. So I'd like to do it >>>> in a callback that is called only once each time when the event queue >>>> becomes empty. Do you have any idea? Or is there any better approach to >>>> updating UI elements? >>>> >>>> Thanks, >>>> Gang >>>> >>>> >>>> _______________________________________________ >>>> gtk-list mailing list >>>> gtk-list@gnome.org >>>> https://mail.gnome.org/mailman/listinfo/gtk-list >>>> >>>> >>> >> >> _______________________________________________ >> gtk-list mailing list >> gtk-list@gnome.org >> https://mail.gnome.org/mailman/listinfo/gtk-list >> >> > > > -- > Jasper >
_______________________________________________ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
