GNOME.org
 

Re: How to add a callback that will be called each time when the event queue becomes empty

Paul,
This is good. Actually I'm thinking about a simpler approach. Any state change causes the callback to be called, which updates all UI elements. Or even simpler. After UI elements are updated, any event causes the callback to be called.

Thanks,
Gang


2013/7/20 Paul Davis <paul linuxaudiosystems com>
the general solution to this is to use any kind of signalling system (g_object signals, boost signals, libsigc++ or whatever you prefer) to post notifications about state changes, and the callbacks/handlers for these signals should queue an idle callback that returns FALSE
 (and only queue it if it is not already queued).

this way the idle callback executes once per batch of state changes, just like the redrawing mechanism of GTK executes only once per batch of events. you want to make sure that your idle callback executes before (higher priority) than the redraw mechanism, so that only one pass through that is required - the redraws initiated by events and those initiated by state changes will be merged into a single "pass"


On Fri, Jul 19, 2013 at 7:53 PM, richard boaz <ivor boaz gmail com> wrote:
hi gang,

so you are aware of every state change then...

back when (2010), i provided a solution for this problem that gets around having to write tons of code for each state change.  you can find my comment and code posting in the thread here:


and i packaged this up into a full-fledged library that you can also find here:


while i agree that many states + many changes can make for too much annoying code writing (hence the solution i found for myself and previously posted), i'm also of the opinion that doing it your way is too passive and will lead to other unforeseen problems, both at the design and implementation levels.

richard


On Fri, Jul 19, 2013 at 2:45 PM, Gang Chen <gang chen cn 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 boaz 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 cn 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



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]