On 3 July 2012 02:10, James Morris <jwm.art....@gmail.com> wrote: > (sorry forgot list) > On 3 July 2012 01:50, David Buchan <pdbuc...@yahoo.com> wrote: >> My understanding is that child threads must never alter the UI in any way. >> >> If I have a program which spawns a child thread to download some data and I >> want to be able to have a dialog pop up should an error occur, is it correct >> to say that I need an idle function to be running concurrently to monitor >> some global variable which would contain the status (set by the download >> thread), and then the idle function would create the dialog pop-up? >> >> Put another way, if only the GTK+ main iteration is allowed to alter the >> GUI, then how does someone get information out of a child thread and to the >> UI? > > Well from what I hear, g_idle_add offers some form of thread safety so > a child thread can communicate some item of data via a callback > executed in the GUI thread. > > The documentation also seems to support this view: > http://developer.gnome.org/glib/2.31/glib-The-Main-Event-Loop.html#glib-The-Main-Event-Loop.description >
Forgive me if I speak as if the thread safety of g_idle_add is something to be doubted. Multi-threaded applications are typically complicated affairs and the ease of use of g_idle_add rather contrasts with my (non-professional) experience. That being said, there are probably limits to what can be accomplished using it but for basic use-cases such as these it is perfect. > your child/download thread does the monitoring of the error status and > when an error is found, use g_idle_add to wait some moments and then > communicate the error to a callback. > > HTH, > James. _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
