Re: [GnomeMeeting-devel-list] Refactoring the addressbook code

[Julien PUYDT <jpuydt free fr>]

Damien Sandras a écrit :
> Le mardi 28 mars 2006 à 11:19 +0200, Julien PUYDT a écrit :
> > Damien Sandras a écrit :
> > > Le mardi 28 mars 2006 à 11:14 +0200, Julien PUYDT a écrit :
> > >
> > > > You cannot do everything with signals, indeed. And I don't want to put 
> > > > glib in opal, but wrap opal with some glib code :-)
> > > Eek!
> > Not all of it, silly, just the IM part ;-)
> >
> > As I said, when audio&video are involved, threading is the way to go 
> > (and gtk+ the way not to go).
>
> I'm not sure I follow you.
>
> Let's imagine we have this :
>
> ---
> Back-end:
> OpalSIPPresenceEP::OpalSIPPresenceEP ();
>
> void OpalSIPPresenceEP::SetState (enum state);
>
> void OpalSIPPresenceEP::OnRemoteContactStateChanged (SIPURL
> remoteContact, enum newState);
> ---
>
> ---
> Front-end:
>
> gm_roster_set_local_state (GmRoster *, enum state);
> gm_roster_set_contact_state (GmRoster *, GmContact *, enum state);
> ---
>
> What do you have in mind?

Both an opal and a glib object, the opal object being the backend's 
backend ; the glib object will be the backend for the rest (ui, dbus, 
whatever).

The implementation would not be pretty but would at least put us safely 
into the glib mainloop :

struct stupid_foo_call_data {
  /* whatever data is needed */
};

void
OpalSIPPresenceEP::Foo ()
{
 /* allocate and populate data, a stupid_foo_call_data */
 g_idle_add (idle_foo, (gpointer)data);
}

static gboolean
idle_foo (gpointer data)
{
  /* data is really a stupid_foo_call_data ; get
   * what is needed out of it, then free it  */

  /* do whatever we want to the glib object : change it,
   * let it emit signals... no problem, we're in the glib mainloop */

  return FALSE;
}

As I said, not pretty.

Snark