[Bug 69430] Make NewChannels, etc., singular?
bugzilla-daemon at freedesktop.org
bugzilla-daemon at freedesktop.org
Tue Jan 28 05:54:45 PST 2014
https://bugs.freedesktop.org/show_bug.cgi?id=69430
--- Comment #54 from Guillaume Desmottes <guillaume.desmottes at collabora.co.uk> ---
(In reply to comment #53)
> > +#include "channel-manager-request-internal.h"
>
> Missing from 7dd315. It doesn't really matter a great deal, since the next
> patch adds it anyway.
Fixed.
> > + /*<private>*/
> > + GObject parent;
> > +
> > + DBusGMethodInvocation *context;
> > + TpChannelManagerRequestMethod method;
>
> If the struct ever has to become public, I'd prefer this stuff to be in
> priv... talking of which, there's no priv pointer. No need to fix that right
> now though.
I don't think it should, TpBaseConnection should be the only one having to use
it directly as it implements Requests. I had to made it public in my WIP commit
only to be able to instantiate a ChannelManager directly.
> > + unsigned yours : 1;
>
> I think we use gboolean (and avoid bitfield syntax) fairly consistently,
> since bitfields are a bit of a trap (they fail if signed, and gboolean is
> signed).
Fixed.
> > + g_return_val_if_fail (method < NUM_TP_CHANNEL_MANAGER_REQUEST_METHOD, NULL);
>
> TP_NUM_..._METHODS
Fixed.
> > + //GParamSpec *spec;
>
> Please delete any remaining commented-out code at the end of the branch, and
> use /* */ for anything intentionally left in.
>
> Please remove get_property, set_property, constructed, dispose unless you're
> going to use them later in the branch.
Done.
> > +void
> > +_tp_channel_manager_request_cancel (TpChannelManagerRequest *self)
>
> Now that we have a little less control over its lifetime, please
> g_return_if_fail (self->context != NULL)
>
> > +void
> > +_tp_channel_manager_request_satisfy (TpChannelManagerRequest *self,
> > + TpExportableChannel *channel)
>
> Here, too
> +void
> > +_tp_channel_manager_request_fail (TpChannelManagerRequest *self,
> > + GError *error)
>
> And here
All done.
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
More information about the telepathy-bugs
mailing list