[gst-devel] Overwriting files in sinks

[Stefan Kost]

hi,

Quoting Sebastian Dröge <slomo at circular-chaos.org>:

> Am Montag, den 01.10.2007, 22:29 +0300 schrieb Stefan Kost:
>> Hi,
>>
>> Sebastian Dröge wrote:
>> > Am Samstag, den 29.09.2007, 13:38 +0300 schrieb Stefan Kost:
>> >> shouldn't this be done as a GInterface? Then an application can   
>> reliably detect
>> >> that it supports it.
>> >
>> > How would this interface look like? Can interfaces contain signals?
>> >
>> Yes, they can.
>> GstFilesystemSinkIface could be a interface name - dunno what else   
>> could fit in
>> there.
>
> Ok, good to know... might be a good solution then :)

One more idea for the interface. It could help to identify the  
property that has the uir/location. Ideally its a interface property  
called "location". But that means elements like playbin will have the  
uri property as legacy (unfortunately there is not G_PARAM_DEPRECATED  
flag, to mark it as such).

It would also be nice to see if it is a local file-path or a uri.  
Regariding this I just wrote an email to gtk-app-devel to see if  
someone already implemented GParamSpecs for a file-path or uri. That  
would then also be enough to tell them apart fromr egular strings.
http://mail.gnome.org/archives/gtk-app-devel-list/2007-October/msg00022.html

Why I need that info? Beause I generate UI for gstreamer elements.

Stefan

>
>> >> Also, emitting a signal is a bit evil, even if it's usually not going to
>> >> be emitted from a streaming thread in this case, since applications will
>> >> probably show a confirmation dialog from the signal callback and run a
>> >> main loop via gtk_dialog_run() or similar, which means there's at least
>> >> the potential for all kind of reentrancy issues that an application
>> >> developer is unlikely to expect.  Not sure what a better solution would
>> >> be though.
>> >
>> > Right, but other options do we have? A GstMessage would be nice but we
>> > need to get feedback from the application somehow...
>>
>> A method in the iface for the reply would be nasty :(
>>
>> Maybe the application should check itself before if the file exists or not?
>
> ...and then we add a property "overwrite" so the application can say
> that the file should be overwritten nonetheless? Would be another
> solution but slightly more complicated for the application.
>
> I guess there's nothing to emit a signal into the thread where the
> callbacks were registered? Then the app-check&property solution might be
> the best...
>
>