GNOME Bugzilla – Bug 750106
splitmuxsink: add a "format-location" signal that allows better control over filenames
Last modified: 2015-08-16 13:41:08 UTC
Created attachment 304266 [details] [review] patch Currently splitmuxsink names files after a string template that is fixated using the sequence number of the file. For some applications this may not be enough, so this patch adds a signal that applications can use to return a custom filename based on whatever criteria they want. In my use case for example, I need the filename to contain the creation date & time.
Seems like a good idea, but I dislike the 'request' part in the name a bit. How about "format-location" ? In Gtk+ similar properties are called "format-value" for GtkScale and "format-entry-text" for GtkComboBox.
(In reply to Tim-Philipp Müller from comment #1) > How about "format-location" ? Sounds good as well. I will change it.
> > How about "format-location" ? > > Sounds good as well. I will change it. Had a chance to do that yet? :)
Created attachment 305990 [details] [review] format-location patch There it is, sorry for the delay.
Comment on attachment 305990 [details] [review] format-location patch Thanks, looks good to me. Please push after adding the bug url to the commit message and a 'Since: 1.6' marker to the signal's gtk-doc chukn.
> Please push after adding the bug url to the commit message and a 'Since: > 1.6' marker to the signal's gtk-doc chukn. (And once git is un-frozen again, sebastian is doing releases at the moment)
commit bbfa46363cf3e7f896ac9ec7e4e3aabea58a59b0 Author: George Kiagiadakis <george.kiagiadakis@collabora.com> Date: Wed Apr 15 18:27:04 2015 +0200 splitmuxsink: add a "format-location" signal that allows better control over filenames In certain applications, splitting into files named after a base location template and an incremental sequence number is not enough. This signal gives more fine-grained control to the application to decide how to name the files. https://bugzilla.gnome.org/show_bug.cgi?id=750106
Note: I did not add the "Since: 1.6" marker because the whole element is new in 1.6
Ah right, makes sense. Thanks.