Germán Diago schrieb:
Cool framework. I hadn't heard of it. Unfortunately, I'm not going to
use it because it adds dependencies and I don't
want more dependencies than boost and gtkmm.
sigx++ only needs tr1 and depends on glibmm when using the library. gtkmm
depends on glibmm, too, so no extra dependencies. tr1 is already available
with some compilers or it is available in newer boost releases.
Anyway, the idea is not to make ANY gtk+ code from another thread
which is not the GUI thread? In my threads code
I use Gtk::Pixbuf::scale_simple to make thumbnails. Does that mean I
cannot use it? Because if I can't I cannot make
multithreaded code for what I want to.
Or maybe I can as long as I don't draw anything in screen, and when the
image is
calculated I send it through a dispatcher and the GUI thread renders
it? Is that the way to do it? Thanks in advance.
You are NOT probibited to call gtk+ code from threads other than the GUI
thread. The point is to make _access_ to objects (e.g. your Gtk::Pixbuf)
threadsafe (use a mutex, e.g.) and avoid calling functions of GUI objects
(like the Gtk::Table or Gtk::Label) from other threads - this will make
things much easier.
So, sending the calculated images through a dispatcher to the GUI thread is
the way to go.
One question remains though: is sharing a Glib::RefPtr<> between multiple
threads threadsafe, given that only one thread at a time accesses the actual
object? Or asked differently: is Glib::ObjectBase::reference() and
Glib::ObjectBase::unreference() threadsafe?
To Germán: please reply to all if you reply to a message...
Klaus
