GNOME Bugzilla – Bug 334290
Add interface for "allow-overwrite" signal in sinks
Last modified: 2018-05-04 08:50:03 UTC
gnomevfssink provides a "allow-overwrite" signal, which can be used to indicate that the destination file should be overwritten if it already exists. Using this in a situation other than directly creating the sink (e.g. gst_element_make_from_uri) is problematic for two reasons: 1) you have to check the type of the sink, such as with g_type_is_a 2) you can't do it for other sinks. It would be good if there was an interface for this that sinks could implement, so applications could do this without sink-specific code.
Why not just something like static gboolean element_has_signal (GstElement *e, const chat *signal_name) { return (g_signal_lookup (signal_name, G_OBJECT_TYPE (e)) != 0); } if (element_has_signal (sink, "allow-overwrite")) { g_signal_connect (...) } This of course makes the assumption that the signatures of the signals are the same where they exist, but I'd expect that to be true for the 2 or 3 elements that will ever have them. Not sure if we need to introduce interfaces for stuff that's only ever going to be used by 2 or 3 elements, but that's just me.
I'm not entirely sure it's needed either, but it was suggested to me on IRC as a way of avoiding messy "is this element a gnomevfsink" code. Another option would be to add signals to the other file sinks, like filesink, with the same prototype. However gnomevfssink's allow-overwrite signal has a parameters of type GnomeVFSURI*, so the new signal would need to be called something else.
Blah, GnomeVFSURI as a parameter to the signal sucks. Using a different name for the signal seems as bad as having them conflict - either one requires the application to know.
Wouldn't this perfectly fit into the GstURIHandler interface?
Not 100% certain putting sink-only properties/methods in GstURIHandler is a wise move. I think this is quite use-case centric and should not require the need for an interface. Also this only applies to sinks that could support such a feature, and we have filesink and giosink ?
Potentially any other sinks that create files, like the curl sinks. Just having an implicit interface by a common signal makes sense though.
Let's close this then. If anybody ever needs this again, a signal can be added to the relevant sinks. As that didn't happen in the meantime, a common interface for such a thing seems too much :)