After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 763814 - dot files: fix enum properties
dot files: fix enum properties
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
Other Linux
: Normal normal
: 1.9.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Reported: 2016-03-17 14:14 UTC by Miguel París Díaz
Modified: 2016-03-28 06:22 UTC
See Also:
GNOME target: ---
GNOME version: ---

rtpjitterbuffer: fix enum description for buffer mode (1.45 KB, patch)
2016-03-17 14:14 UTC, Miguel París Díaz
rejected Details | Review
jitterbuffer graph (28.54 KB, image/png)
2016-03-17 17:34 UTC, Miguel París Díaz

Description Miguel París Díaz 2016-03-17 14:14:28 UTC
Created attachment 324187 [details] [review]
rtpjitterbuffer: fix enum description for buffer mode

The enum values description and names were in a wrong order
Comment 1 Tim-Philipp Müller 2016-03-17 17:24:32 UTC
Comment on attachment 324187 [details] [review]
rtpjitterbuffer: fix enum description for buffer mode

Could you elaborate why you think the order should be changed?

GEnumValue clearly has 'nick' as last structure member, and we use the same order elsewhere.
Comment 2 Miguel París Díaz 2016-03-17 17:34:54 UTC
Created attachment 324204 [details]
jitterbuffer graph

In the property show in the graph we can see: "mode=((RTPJitterBufferMode) Synchronized sender and receiver clocks)"

We want this instead of showing "mode=((RTPJitterBufferMode) synced)"?
Comment 3 Tim-Philipp Müller 2016-03-17 18:05:55 UTC
Ah, I see.

I think this is a problem in the dot file generation code.

The thing with these enums is that GEnumValue doesn't have a field for 'description', so what we do is that for non-public enums we (ab)use the 'name' field for the description. For public enums that would typically match the enum in the header, so e.g. GstAudioSink slave-method would have:


while for non-public API it's the description.

I think the dot file generation code should just always use the nick here, it's shorter and will work in both scenarios.
Comment 4 Miguel París Díaz 2016-03-18 10:23:44 UTC
So, can we forget this patch and apply another one in the dot file generation?
Comment 5 Tim-Philipp Müller 2016-03-18 10:36:47 UTC
Yes, please. Will you make a new patch?
Comment 6 Miguel París Díaz 2016-03-18 10:40:07 UTC
If you do not mind, I would prefer that you do it when you can, I am sure that it will take less time for you than for me ;).
Comment 7 Sebastian Dröge (slomo) 2016-03-22 09:19:07 UTC
For extra fun, GstPreset has the same problem. Resulting in things like "frame-packing=Automatic (use incoming video information)" (this is from x264enc) in the generated preset files. Changing that one is more tricky as we need to keep backwards compatibility...
Comment 8 Tim-Philipp Müller 2016-03-26 17:30:25 UTC
We should probably clone this bug for GstPreset?

This should fix it for the dot files:

 commit 9e836805632a1da98622c13f64ba130e01e64eda
 Author: Tim-Philipp Müller <>
 Date:   Sat Mar 26 17:21:51 2016 +0000

    debugutils: fix enum/flag properties printing for elements
    We want to use the flag/enum nicks here, not only because they
    are shorter but also because in case of element-specific enums
    and flags we abuse the enum/flag name field for the description,
    and we don't want that printed in the dot file.
Comment 9 Miguel París Díaz 2016-03-28 06:22:24 UTC
Thanks Tim ;).