Ah ok, yes I get you now.
Unfortunatly pkg-config tells me this:
pkg-config --libs gtkmm-2.4
-pthread -lgtkmm-2.4 -latkmm-1.6 -lgdkmm-2.4 -lgiomm-2.4 -lpangomm-1.4 -lgtk-x11-2.0 -lglibmm-2.4 -lcairomm-1.0 -lsigc-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0 -lm -lpangocairo-1.0 -lcairo -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt -lglib-2.0
So there's quite some deps for 2.4, I don't know if gtkmm-3 has less dependencies (I haven't switched yet) but I doubt it somehow. The reason that all threading / OS specific stuff is abstracted & "generic"-ized across platforms is so that the same source will compile cross platfrom... you're probably well aware of this.
That means that if your using GTK, your going to need the GTK subsystem for files, threads, X, name it... because some of them are platform specific, I don't know is it possible to use the generic C++11 or C++0x threads as a *replacement*, although I'm sure you can use them as an *alternative*.
I'm not a gtkmm-dev, so I'm in over my head a little here... Perhaps some of the veterans of this list would like to shed some light on if its practical to do what the OP mentions...
I'll be keeping an eye on the thread for my own learning... :) -Harry
On Sun, Oct 16, 2011 at 7:44 PM, Chris Gordon-Smith <c gordonsmith gmail com> wrote:Hello Harry
Thanks for the response.
What I want to do is minimise the dependencies that my code has on
various libraries other than the C++ standard library.
Since the C++ standard library does not include a GUI, I use GTKMM,
which I'm very happy with. I have separated out my GUI presentation code
from the rest of the code, and only the GUI presentation code has to
include <gtkmm.h>. But to get the multithreading for the GUI working, I
have now had to introduce a dependency on Glib <glibmm.h> in other parts
of my code. I have used wrapper classes to limit the scope of the
dependency to a small section of code, but I would have preferred not to
do this at all.
My question is: Could I have avoided use of Glib::Thread altogether, and
just used std::thread?
I think probably not, but thought I would ask.
Chris Gordon-Smith
www.simsoup.info
On Sun, 2011-10-16 at 17:44 +0100, Harry van Haaren wrote:
> Hi Chris,
>
> From experience: Of course it is, if you 1. mutex critical sections
> or 2. lock-free ringbuffer all events between the threads, there's
> no reason you can't use 2 (or more) different "types" of threads in
> one app.
>
> From a practical point of view, why would you? Glib::Thread should
> suffice for simulator / GUI separation...
>
> Perhaps I'm not following your use-case, or maybe you want to play
> with the latest-and-greatest, I don't know.
> I know there's some convenience things around std::thread that you
> might want for ease of use.. but I've always
> coded those myself..
>
> -Harry
>
> On Sun, Oct 16, 2011 at 4:28 PM, Chris Gordon-Smith
> <c gordonsmith gmail com> wrote:
> Hello All
>
> I have recently introduced multi-threading into my artificial
> chemistry
> simulator, so that the GUI can be active while the simulation
> is
> running.
>
> To do this, I've used Glib::Thread. Now that C++11 provides
> threading
> with std::thread, I would prefer to use that. Is it possible
> to use
> std::thread so that I have one thread for my GTKMM GUI, and
> one (or
> more) for my simulation processing?
>
> Chris Gordon-Smith
> www.simsoup.info
>
> _______________________________________________
> gtkmm-list mailing list
> gtkmm-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtkmm-list
>