[Bug 32053] Add a TpContactSearch proxy object

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=32053

--- Comment #29 from Emilio Pozuelo Monfort <pochu27 at gmail.com> 2011-01-19 06:27:38 PST ---
(In reply to comment #28)
> + * Returns: (transfer full): a new contact search channel, or %NULL
> It's not a TpChannel either.

OK, hopefully fixed for good...

> + *  it when you're done with %g_list_free.
> Is that properly linked? I'd say it should be "g_list_free()".

I've checked, and it is. I've changed it to () for consistency though.

> I think the long description in SECTION:contact-search should describe the
> whole search process (which function use to start a search, how to get the
> results and then how to start a new search).

I've added a paragraph explaining how a normal search would be done.

> Actually having a simple demo app in examples/client could be useful.

Can we postpone this? I'd like to get contact search in Empathy, and the UI
freeze is in ~ 1 week, and it's blocking on this.

> You add your new files to telepathy-glib/introspection.am so they'll be added
> to gir.

Done (and checked the .gir file).

> (In reply to comment #27)
> > >       g_cancellable_cancel (self->priv->cancellable);
> > > 
> > >       while (self->priv->async_res != NULL)
> > >         g_main_context_iteration (NULL, TRUE);
> > > This is a bit weird; maybe we should request a g_cancellable_cancel_async() in
> > > glib?
> > > Do we really need to wait btw ?
> > 
> > As it is now, yes, since we use the same GCancellable, so we need to wait and
> > reset it. Maybe we could have a list of GCancellables and just cancel it
> > without waiting, or maybe we can cancel it and unref it (if gio cancells it
> > before disposing the GCancellable), so we don't need to keep a list. The
> > current code works though.
> 
> The cancel, unref and create a new one option sounds saner to me. Can you
> check the GCancellable implementation and/or test to see if that would work?

I've just done it, and it works. AFAIK when you _unref an object and the ref
count gets to zero, the object is disposed directly (i.e. synchronously), so
this is probably the same we were doing, but nicer / less hacky.

> > > tp_contact_search_start(): shouldn't we check if another search is already
> > > active?
> > 
> > We do:
> > 
> >   g_return_if_fail (self->priv->state ==
> >       TP_CHANNEL_CONTACT_SEARCH_STATE_NOT_STARTED);
> 
> You're right sorry.
> 
> > > +  if (with_limit)
> > > if (with_limit != NULL)
> > > 
> > > +      if (!tp_strdiff (chan_type, TP_IFACE_CHANNEL_TYPE_CONTACT_SEARCH))
> > > use "continue" to limit nesting.
> > 
> > I cannot use "continue" there since I have to check both with_limit and
> > with_server, and if I continue in the first one, I won't get to check the
> > second one. I could do
> > 
> > if (with_limit != NULL && !tp_strdiff (...))
> > 
> > to avoid one level. Not sure if it's worth it...
> 
> I meant doing:
> if (tp_strdiff (chan_type, TP_IFACE_CHANNEL_TYPE_CONTACT_SEARCH))
>   continue;
> 
> Wouldn't that work?

Oh, right. Done, thanks.

> > > Having test for TpContactSearch would make me an happier badger...
> > 
> > I tried to look at this, but apparently I need to create some classes for the
> > DBus tests and I couldn't really understand how that stuff works.
> 
> Yeah you have to write a server side channel object to test your API.
> See for example tests/lib/stream-tube-chan.c tested in tests/dbus/stream-tube.c

Same as for the example... can we do this later? I don't really have the time
right now to get into this, and I'm sure this will take me quite some time as
I'm not familiar with this dbus test stuff.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.