GNOME Bugzilla – Bug 711681
Remove usage of deprecated GValueArray in rtpsession
Last modified: 2013-11-18 13:17:37 UTC
Created attachment 259269 [details] Proposed fix for this issue Currently rtpsession uses GValueArray as response when querying for its sources. This is deprecated in GLIB and GArray should be used instead.
Don't think this is possible. Unfortunately GValueArray was deprecated without any replacement suitable for our use cases. There is no way for us to communicate to dynamic bindings what the content of that GArray.
Do you mean for backwards compatibility of the dynamic library? I understand that it would be an "invisible" interface change if we change the return type, and no one would detect it until it was too late. I guess an alternative would be to add a new function which exposes a "sources_2" (maybe not a good name) which uses GArray and keep the other as is. If users needs to use GValueArray way they need to use the GLIB_DISABLE_DEPRECATION_WARNINGS flag in their code right?
No, the problem is that there is no way to know what the content of a GArray is without looking at the gir file. And it is currently not possible to have gir files for plugins.
What we could do is add some gst_structure_get_array() helper API (maybe along with _get_{float,int,double}_array()) which applications can use. That would then be annotated. Has some additional overhead of course, but for the use cases where it would be used that's probably not so important.
This isn't a GstStructure, this is a GObject property that's a GValueArray, so it's stuck in stone (as this bit is API stable) until 2.0 anyway.
Ah yes, sorry, I context-switched to the more common GValueArray problems. Yes, the property has to stay like that unfortunately. I wish GLib folks would just un-deprecate this again.
Ok I see, but how can one for example know that there are GObjects and not for example guint's in the GValues? I guess the only documentation for this is in the code when you install the property? g_object_class_install_property (gobject_class, PROP_SOURCES, g_param_spec_boxed ("sources", "Sources", "An array of all known sources in the session", G_TYPE_VALUE_ARRAY, G_PARAM_READABLE | G_PARAM_STATIC_STRINGS)); If one were to specify that for example "An array of all known sources in the session stored as GValues", wouldnt that be sufficient? I understand that it would be hard to do a non backwards compatible interface change, but would it be possible to extend the interface with a new parameter that uses this? I dont thing GLib will un-deprecate their type anytime soon... Let me know what you think!
Code can know what type a GValue with the G_VALUE_TYPE macro, which returns the GType of the contained data. There's no equivalent for GArray to know that the content is GValues. We could just subsume the GValueArray type, or make a GstTypedArray and make the introspectors suck it up.
I dont think we can subsume the type due of the lack of an interface. I agree that it would be nice to have a typed array in GLib, but im not aware of any (besides GValueArray)?
Ok I will add a new type GstTypedArray which can be queried for the type of its contents. Where (which plugin) should I add the new type?
I don't know if that is something we are very keen on, we have decided no to go down this path in the past.
Ok, but somehow this needs to be solved? I guess GLib marked this parameter as deprecated because they are going to remove it in the future. So what happens then? Did you find any alternative solutions to this problem (except using GLIB_DISABLE_DEPRECATION_WARNINGS) in the previous discussions you had?
It is not going to be removed in the GLib 2.x series.
Ok.