Chris Vine wrote: > On Saturday 23 September 2006 12:24, Pavel Rojtberg wrote: >> Since I could not find any gtkmm threading tutorial that covers glib >> threads with use of gtkmm, I relied on the pygtk documentation: >> http://www.async.com.br/faq/pygtk/index.py?req=show&file=faq20.001.htp >> >> I used Glib::thread_init() instead of gobject.threads_init(), but could >> not find any equivalent for gobject.idle_add(), so perhaps that is where >> my problems originate from. >> >> Anyway the problem is that sometimes the interface just stops being >> updated while still emmiting events, so I can use the close button. > > You cannot access GTK+ in more than one thread without using the global GDK > lock (and you cannot do it all, with or without the GDK lock, under windows). > > This explains how GTK+ interacts with glib threads: > http://developer.gnome.org/doc/API/2.0/gdk/gdk-Threads.html > > To post events using gtkmm, see Glib::Dispatcher. You can also use the raw C > function g_idle_add() if you wish, but this is not wrapped in glibmm > (presumably because glibmm provides Glib::Dispatcher, which glib does not). > Either of these will execute the callback in the thread in which the main > program loop (and by default GTK+) execute, so avoiding the need to use the > GDK global lock. If you use g_idle_add(), make sure the handler returns > FALSE so that it only fires once. > > Chris thanks for your reply. meanwhile I asked on the IRC and came out with the Glib::signal_idle().connect(), which is as far as I can see the equivalent of g_idle_add().
But while trying to use it I noticed that sigc++ does not work with Glib::RefPtr - I just could not bind Gtk::TextBuffer::insert without a wrapper function... Anyway which implementation would hou consider as the cleaner one signal_idle or dispatcher? Pavel _______________________________________________ gtkmm-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtkmm-list
