telepathy-glib should use glib-mkenums to generate tp-enum-types.[h|c], so that it can register correct types for signals and properties.
For instance, that would allow the attached patch to work.
It's difficult to integrate glib-mkenums into a Makefile.am, particularly when you are generating other code already. Pango is probably a good example:
Created attachment 19649 [details] [review]
In the case you attach a patch for, we can't fix this without breaking ABI; we'll aim to do this right in future when adding new enums not exposed in the D-Bus API, and I'm marking this bug as one we can deal with when we decide to break telepathy-glib's ABI.
In the cases where enums come from the Telepathy D-Bus specification, we can't fix this because dbus-glib expects G_TYPE_UINT for them, rather than some GType corresponding to a GEnum.
This would also allow us to use g_value_set_enum() instead of g_value_set_int(), as people expect when writing code, for instance when setting a GValue to TP_HANDLE_TYPE_CONTACT.
(In reply to comment #2)
> In the cases where enums come from the Telepathy D-Bus specification, we can't
> fix this because dbus-glib expects G_TYPE_UINT for them, rather than some GType
> corresponding to a GEnum.
This seems like an error in your code that calls dbus-glib. Surely you can just transform the type where necessary.
So I recently asked why the new TpAccount wrapper-API wasn't using GEnums and was pointed to this bug.
It seems to me like we could possibly use GEnum in new API, except for the following problems:
* API would be inconsistent between old and new APIs
* GEnum is strict about guarding against values outside the range, this is a problem if the other end is using a newer version of the Telepathy spec.
It's possible that the second problem could be fixed with the addition of a g_value_force_enum(), which would be like set_enum() but without the bounds checking. The idea being that you enforce enum bounds checking on the API side, but you accept any incoming value on the D-Bus side.
I wonder if, even if it's not used in the API, it's worth adding glib-mkenums to the build, so that we can dump the names of specified enum values for debugging with g_enum_get_value().
I'm going to call this FIXED, since Danielle added enum/flags types for all the hand-written enums.
TpConnectionManager:info-source is still of type UINT since otherwise it'd be an ABI break, but this is now flagged in the documentation.