Re: [Ekiga-devel-list] Unthreading ekiga : a strategy
- From: Damien Sandras <dsandras seconix com>
- To: Ekiga development mailing list <ekiga-devel-list gnome org>
- Subject: Re: [Ekiga-devel-list] Unthreading ekiga : a strategy
- Date: Mon, 16 Apr 2007 14:02:33 +0200
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]