On Wed, 1 Jun 2011 10:44:02 +0800 Gang Chen <gang.chen.cn@xxxxxxxxx> wrote: > Hi Lothar, > > Thank you for your information! Maybe they are not so bad for me. My > app has a simple GUI, and uses a drawing area to display text with > some decorations. If my app can work fine on windows, linux and OSX > without too many hacking efforts, I'll be satisfactory. Actually, my > main concerns are about multithreading (I chose to use boost::thread > and boost::threadpool) and gtkmm (it seems to be incomplete; not sure > about its quality). The X11 backend for GDK has a lock available for multi-threaded access, but you can't use the GDK global lock with the windows/GDI backend. On windows you must make all calls to GDK/GTK in the main program thread. (This is more restrictive than GDI requirements, but only just, which require all calls to controls to be made in the thread which creates them.) If you are using raw GTK+ then the easiest way to do this is to post event callbacks using g_idle_add(), because the glib main loop is thread safe. If you are using gtkmm, you can use Glib::Dispatcher for the same purpose (or a thread-safe C++ wrapper for idle sources, of which there are some available such as in c++-gtk-utils, but they are relatively easy to write yourself). However note that libsigc++, which gtkmm uses, is not thread safe, so the best rule is only to call libsigc++ methods in the main GUI thread. boost of course has a thread-safe signal/slot implementation (boost::signal2) so if you use that you can restrict the use of libsigc++ to the GTK+ thread only, provided you are careful about the use of sigc::trackable. Chris _______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
