Re: Threads and idle functions
Hi Igor, On Tuesday, 3 July 2012, Igor Chetverovod wrote Hi David, probably you should use macros: gdk_threads_enter () gdk_threads_leave (). Those macros were used to lock the main gdk thread in earlier versions of gtk if you wanted to call gtk_ functions from many threads. They are now deprecated, I think, and you are only supposed to call gtk functions from the main thread. They are not necessary for g_idle_add(). ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Threads and idle functions
(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 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
Re: Threads and idle functions
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
Re: Threads and idle functions
yep. Seems to be working. Thanks! Dave From: James Morris jwm.art@gmail.com To: David Buchan pdbuc...@yahoo.com Sent: Monday, July 2, 2012 9:10 PM Subject: Re: Threads and idle functions 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 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. Dave ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Threads and idle functions
Hi David, probably you should use macros: gdk_threads_enter () gdk_threads_leave (). Best regards, Igor 2012/7/3, David Buchan pdbuc...@yahoo.com: 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? Dave ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
