Bug 7763

Summary:	GLib: GEnum in signals are not marshalled.
Product:	dbus	Reporter:	Steve Frécinaux <nud>
Component:	GLib	Assignee:	Rob Taylor <rob.taylor>
Status:	RESOLVED WONTFIX	QA Contact:	John (J5) Palmieri <johnp>
Severity:	enhancement
Priority:	low
Version:	unspecified
Hardware:	x86 (IA32)
OS:	Linux (All)
Whiteboard:
i915 platform:		i915 features:
Attachments:	Marshall-flags-enum Lookup-derived-types-before-failing Don't assert on unknown type, just skip them

Description Steve Frécinaux 2006-08-03 18:47:15 UTC

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).

Comment 1 Marc-Andre Lureau 2008-09-29 23:43:35 UTC

I am interested too. Same approach, let's use the nick.

Comment 2 Marc-Andre Lureau 2008-10-04 14:43:58 UTC

Created attachment 19374 [details] [review]
Marshall-flags-enum

Comment 3 Marc-Andre Lureau 2008-10-04 14:44:33 UTC

Created attachment 19375 [details] [review]
Lookup-derived-types-before-failing

Comment 4 Marc-Andre Lureau 2008-10-04 14:45:36 UTC

Created attachment 19376 [details] [review]
Don't assert on unknown type, just skip them

Comment 5 Marc-Andre Lureau 2008-10-04 14:48:24 UTC

depends on http://bugzilla.gnome.org/show_bug.cgi?id=447907 patches (enum/flags transform)

Comment 6 Marc-Andre Lureau 2008-10-11 10:07:34 UTC

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)

Comment 7 Simon McVittie 2011-01-26 08:59:26 UTC

(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.

Comment 8 Simon McVittie 2011-05-10 02:01:31 UTC

(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.