[Bug 28413] Gabble DTMF

[bugzilla-daemon at freedesktop.org]

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

--- Comment #14 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2010-10-25 07:13:02 PDT ---
(I've merged Jonny's call-dtmf branch into my dtmf branch, and will merge it to
master at the same time.)

(In reply to comment #10)
>  * gabble_dtmf_player_play has loads of g_return_val_if_fail to check for bad
>    arguments, but doesn't check whether self is what it should be, so you could
>    easily pass NULL into it, etc.

Fair enough, I'll poke at that.

>  * Just a nitpick, but the sig_id_started_tone IDs are fine, but just different
>    from (I believe) everywhere in gabble and tp-glib. Why didn't you do the
>    standard thing of creating a signals array and enum?

No particularly compelling reason; I suspect the signal pseudo-ID enum is
mostly cargo-culted from the property ID enum, which is made necessary by
GObject's API (signal IDs are provided by GObject, whereas property IDs are
provided by each class with properties, hence the discrepancy), so I'm trying
out a different approach.

I'm not sure that having the signal pseudo-ID being an index into an array
containing the *actual* IDs gains us any clarity - it just means we have an
extra sort of small integer involved - but for some reason it's become
conventional, and if you'd prefer consistency here, I can easily do that.

> I have already ++'d your spec branch, so I say merge that, and merge your dtmf
> branch. It's up to you what you want to do about the new spec stuff

I'm inclined to merge dtmf now, then uncomment the new stuff after the next
spec/tp-glib release (which I want to do pretty soon anyway, so they might both
land in the same Gabble release, in practice). I might also delete
GabbleDTMFPlayer in favour of TpDTMFPlayer at that point.

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