GNOME Bugzilla – Bug 529300
[giosink] [PATCH] Allow overwrite
Last modified: 2009-07-08 14:57:51 UTC
Attached is a patch to allow the use of g_file_replace if appropriate. It is modelled after gnomevfssink's support for same.
Namely, giosink emits a signal asking if it can overwrite the file. If yes, it uses g_file_replace.
Created attachment 109663 [details] [review]
something like this is definitely needed but it was decided that it is a bad idea to emit signals from the elements to query the application for information.
The signal is emitted from a random thread and the application has to care about proper dispatching to the thread running the Gtk main loop for example and then can show a dialog and has to dispatch the result back to the other thread.
What we need is a general mechanism for asking the application for information... probably something going over the bus like a message with a new flag to mark it as requiring an answer, add a gst_element_post_message_with_reply() that waits until a reply is there (or a timeout happend?), etc...
Created attachment 109791 [details] [review]
Overwrite using property
Fair. Would you accept this patch, which uses a property to set the default overwrite behavior? For my needs (sound-juicer's port to gio), this is sufficient. And it doesn't preclude one day having the more powerful 'asking' behavior.
The approach I took in rhythmbox was to create the output stream myself and use a giostreamsink, rather than letting giosink do it. This way, if g_file_create returns a G_IO_ERROR_EXISTS error, we can ask the user if they want to overwrite and then use g_file_replace to create the stream. Once this is all done, we set the 'stream' property on the sink element. This all takes place during pipeline setup, so there's no need for communication between app and streaming threads.
See the attach_output_pipeline function here: http://svn.gnome.org/viewvc/rhythmbox/trunk/backends/gstreamer/rb-encoder-gst.c?view=markup
IMHO the best fix would be a custom element message posted on the bus. Applications can catch that and ignore the following error message, delete the old file and then start the pipeline again.
This has to be handled similar to missing plugins, i.e. if the message is on the bus ignore all error messages, do something (remove the file, use a different location) and then the pipeline can simply be started again.
Author: Sebastian Dröge <email@example.com>
Date: Wed Jul 8 16:55:41 2009 +0200
gio: Post a custom file-exists message on the bus if the file already exists
An application can handle this message, remove the file in question
and restart the pipeline again without showing an error.
This fixes bug #529300.