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: http://svn.gnome.org/viewvc/pango/trunk/pango/Makefile.am?view=markup
Created attachment 19649 [details] [review] 0001-2008-10-14-Murray-Cumming-murrayc-murrayc.com.patch
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.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.