Using the GLib bindings, a signal taking a GEnum (or derivative) as an argument should be marshalled using the actual value nick of the argument. GEnumValue nicks are prefered since enum values are usually not precisely known and moreover, hard to remember and to use in other languages than C. A possible solution could be to define a marshaler for G_TYPE_ENUM, and then to have a way to get the parent types of the current one (same solution as for bug 7762).
I am interested too. Same approach, let's use the nick.
Created attachment 19374 [details] [review] Marshall-flags-enum
Created attachment 19375 [details] [review] Lookup-derived-types-before-failing
Created attachment 19376 [details] [review] Don't assert on unknown type, just skip them
depends on http://bugzilla.gnome.org/show_bug.cgi?id=447907 patches (enum/flags transform)
poing! nobody interested to get this merged? Any comment on the approach of using string vs int? (the glib patch is required only for the client side to be able to convert from string to int)
(In reply to comment #6) > nobody interested to get this merged? Apparently not... This seems to be a feature depending on an unfixed GObject bug, and dbus-glib doesn't get enough maintainer time to keep up with bugs, let alone add features, so, low priority. Sorry. (In reply to comment #6) > Any comment on the approach of using string vs int? FWIW, Telepathy's enums/flag sets are all represented as uint32 on D-Bus, except one which uses a single byte (it's derived from an RFC that encodes DTMF in one byte, so there'll never be more than 256 values). The interface implemented by dbus-daemon itself also puts enums/sets of flags on D-Bus as integers. The fact that we disagree on how to encode GEnum on D-Bus suggests that there's no single obvious answer, so I think "explicit is better than implicit" applies: send the string or the integer, as appropriate. One non-obvious problem with a GEnum on D-Bus is that GEnum properties and signal arguments are intolerant of out-of-range values, but if someone sends you an integer over D-Bus, it could have any value. As a general principle, D-Bus services and clients shouldn't be remotely-crashable.
(In reply to comment #7) > The fact that we disagree on how to encode GEnum on D-Bus suggests that there's > no single obvious answer, so I think "explicit is better than implicit" > applies: send the string or the integer, as appropriate. WONTFIX on this basis.
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.