Re: Glib::Dispatcher: How to use a non-void signal for tunneling?

[Vinzenz 'evilissimo' Feenstra <mailinglist evilissimo-softdev de>]

hmm, I am not sure if you're looking for somthing like Glib::Cond

http://www.gtkmm.org/docs/glibmm-2.4/docs/reference/html/classGlib_1_1Cond.html

Have a look at the example. Maybe it is what you're looking for.

BR
Vinzenz 'evilissimo' Feenstra

Matthias Kaeppler schrieb:

> Hi Vinzenz,
>
> thanks for the material, much appreciated, I'll give it a shot asap 
> (since I happen to be from Germany, it's not even a language issue).
>
> Meanwhile, I managed to get everything to work by intercepting the 
> object in question on each progress-update and copy all the data I 
> need over to the dialog, such that it's still valid after dispatching 
> the cross-thread GUI-update (that was not the case with the info 
> object, that's why my code segfaulted).
>
> I'd have another quick question though if you don't mind; it's more of 
> a general question and does not relate to an error in my code or so:
>
> My problem is that I'm not quite sure /when/ I have to dispatch a 
> call. The case with the dialog was pretty clear, because I had to 
> modify its interface (e.g. move the progress bar, set new text etc.), 
> and these actions included direct modification of the GUI.
>
> But what about this:
>
> In the non-GUI thread a signal handler is called by the async transfer 
> method. In this signal handler I check in which phase the transfer is, 
> etc. At some point I spawn the transfer dialog using Dialog::show() 
> and at some other point I hide it when the transfer has finished.
> I am /not/ dispatching these calls; but since these calls invalidate 
> parts of the main window (the area where the dialog appears has to be 
> redrawn of course), maybe I should do that? IOW, I am calling show() 
> and hide() directly from the non-GUI thread. For now, I found it 
> overly complicating my code to introduce another dispatcher just to 
> dispatch calls to show() and hide()!
>
> For now, I haven't had any trouble with that, but wouldn't these two 
> calls strictly speaking have to occur in the GUI thread? How can I see 
> which calls classify themselves to be absolutely necessary to be 
> called from the GUI thread and which don't? The documentation is not 
> clear in that point.
>
> Any clarification appreciated.
>
> Best regards,
> Matthias