Re: [Ekiga-devel-list] Unthreading ekiga : a strategy



Le lundi 16 avril 2007 �4:03 +0200, Julien Puydt a �it :
> Damien Sandras a �it :
> > I think this is for post-3.00. We'll see.
> 
> Yes, we'll see. But it aches when we debug other peoples' threading issues!
> 

Until now, except for the accessibility issues, I have never debugged
any threading issue related to GTK+ itself. (only deadlocks or missing
locks in OPAL itself).

> > However, what I have in mind is to trigger a signal, and the interested
> > GUI parties listen to it.
> 
> Beware : you'll still need to go to the gui thread before you fire the 
> signal!
> 
> But it's indeed the principle :-)
> 
> > That is the only clean approach. If you use glib, then the GUI can not
> > entirely be abstracted out of the OPAL specific code.
> 
> Notice : glib isn't GUI.
> 

It is still a C dependance part of GTK+.

> I use libsigc++ for signals in my latest contact code : 
> http://libsigc.sourceforge.net/

I think it is better :
- Endpoints fire signals
- the GUI thread listens to them and acts consequently
-- 
 _     Damien Sandras
(o-      
//\    Ekiga Softphone : http://www.ekiga.org/
v_/_   NOVACOM         : http://www.novacom.be/
       FOSDEM          : http://www.fosdem.org/
       SIP Phone       : sip:dsandras ekiga net
                       




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]