Re: Compiling a GTK application on windows

[Chris Vine <chris cvine freeserve co uk>]

On Wed, 1 Jun 2011 10:44:02 +0800
Gang Chen <gang chen cn gmail com> 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