I hope translation from the German won't be necessary :-). I think the
documentation and examples of dispatcher use are more intimidating than
they should be.
In your main thread, create a dispatcher object.
"Connect" the object to a routine that draws.
In your separate thread, call the dispatcher when you want to draw.
The routine you created in the second step gets invoked by the secondary
thread but in the context of the first.
It's really just a few lines, and it's an awesome concept, but it's
obscured by the many pages of documentation and sample code :-^.
-- Alan
P.S. I don't know why it doesn't take arguments either, but one can
work around that with globals and a mutex.
On 8/1/2013 9:18 AM, Jonas Platte wrote:
Yes I know that this should be solved with a seperate thread and I now
have read the documentation for Glib::Dispatcher and understand the
basics of it, even though I don't understand why it doesn't allow
arguments.
I also found an example for this with a lot of comments (in german, I
could translate it if you think that is simpler than writing another):
http://www.c-plusplus.de/forum/p816067
And to the poster: You were right, the implementation is really not
_that_ complicated :)
Am 01.08.2013 17:48, schrieb Alan Mazer:
Jonas, the suggested approach that I sent earlier uses a dispatcher
to avoid this problem, which I think is the preferred approach.
Also, the poster is trying to update a GUI window *asynchronously*.
He doesn't want to use timeouts, and he doesn't want it to be button
driven. I think that justifies the use of a separate thread.
-- Alan
On 8/1/2013 7:24 AM, Jonas Platte wrote:
It is quite simple to open another thread and call set_text of your
label from there. The problem is that this will probably crash your
program, as gtkmm is not thread-safe. That's why you need to make
sure that your set_text doesn't overlap with the gtk main loop that
updates the GUI.
And _that_ is the thing complicated to implement. At least I think
so. I never did this before, but you made me think about this once
again and it raised my interest, so eventually I will come up with a
solution later. Or somebody else will.
_______________________________________________
gtkmm-list mailing list
[email protected]
https://mail.gnome.org/mailman/listinfo/gtkmm-list
_______________________________________________
gtkmm-list mailing list
[email protected]
https://mail.gnome.org/mailman/listinfo/gtkmm-list
_______________________________________________
gtkmm-list mailing list
[email protected]
https://mail.gnome.org/mailman/listinfo/gtkmm-list
