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 : 

I think it is better :
- Endpoints fire signals
- the GUI thread listens to them and acts consequently
 _     Damien Sandras
//\    Ekiga Softphone :
v_/_   NOVACOM         :
       FOSDEM          :
       SIP Phone       : sip:dsandras ekiga net

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