GNOME Bugzilla – Bug 483250
[0.11] GstURIHandler should use interface properties instead of (or additional to) get/set methods
Last modified: 2013-07-18 12:12:12 UTC
Hi, see [0] for an explaination why this would be useful. Bye [0] http://sourceforge.net/mailarchive/message.php?msg_name=4703EF65.9010208%40hora-obscura.de
why 0.11? can't it be done by just adding the properties without breaking API/ABI?
It would mean that all elements implementing GstURIHandler would have a common standard property that stores the URI. This one should most probably be named "uri", but this means that all elements that already have a "location" property grow another property that does exactly the same. I love this idea (for 0.11); it seems to bring the best of everything: - The inability of setting the URI from a launch line is resolved elegantly. From time to time, people request that a property to set the URI is added to element XY because of this. You know something is wrong with the design if you find yourself being on both sides (for and against this) in different cases (note how I gave the gio elements location properties, while I'm otherwise stricly against this, eeek). - Generated UIs for property manipulation lose redundancy (Stefan's remark). This is because apps will know exactly that the "uri" property is from the interface, which means they can hide it if they set the URI elsewhere and they can drop special handling of the URIHandler interface (which you need for 0.10). - Unless elements explicitely override the details of the param spec, the "uri" property of all URIHandlers will have a consistent description automatically. I think doing this for 0.10 already (with the property named "location" instead) causes more problems than it solves.
I think it can be added and it won't break anything. In buzztard where I generated UI, I'll probaly add some special case handling for elements that have URIHandlerIface and both uri and location properties.
Well, it could be done for 0.11 I guess without breaking anything. But as René pointed out this will cause two properties for the same thing in quite a few elements. Not sure if this confusion is worth it... Also (pure theory) some element could already have an "uri" property that does something different than what we want here... Whatever, if people think this can and should be implemented already for 0.11 that's fine ;)
Setting target milestone to 0.11.x
Let's close this as WONTFIX then, apparently not enough interest in doing this :)
We should have done this in 1.0 really. Now we'll have to wait for 2.0. Why are you closing this btw. Or differently askes, how would an application discover that the STRING property name uri takes a uri?
You would use the GstURIHandler interface if you want to work with all elements. I agree that it would be nice to have, but apparently nobody was interested enough to work on that in the 2 years in which 1.0 was developed so why should that change for 2.0 in a few years?