GNOME Bugzilla – Bug 594954
[PATCH] play 'complete-media-burn' event sound when finished burning CD
Last modified: 2009-09-18 10:02:39 UTC
Created attachment 143036 [details] [review] the patch This patch simply calls ca_gtk_play_for_widget() on the burn dialog when a CD finished burning. Depending on the sound theme used this should trigger a nice completion sound (currently a 'bing' like from a microwave in the upstream sound-theme-freedesktop).
Thanks a lot; that will be a real nice addition but a bit late apparently for the 2.28 timeframe. But I'll commit it first thing when we'll branch for 2.30 which should happen soon. Just a few questions though: - why do you use gtk_widget_show ()? I suppose you need the dialog to be displayed to play the sound; right? - one thing (that I can take care of myself if you are too busy now you showed me the way) that would be nice would be to play the sound in the following situations: . a dummy session has taken place and brasero is about to start burning for real . after blanking/formatting (in brasero-burn-blank-dialog.c) has been performed You also seem to forget to play the sound when the first disc of a spanned session has been burnt. I was not sure if these were valid cases or if they fit the specs so I wanted to have your opinion.
(In reply to comment #1) > Thanks a lot; that will be a real nice addition but a bit late apparently for > the 2.28 timeframe. But I'll commit it first thing when we'll branch for 2.30 > which should happen soon. > > Just a few questions though: > > - why do you use gtk_widget_show ()? I suppose you need the dialog to be > displayed to play the sound; right? The gtk_widget_show() is not strictly necessary. If you drop it the sound will still be generated. However, when the dialog is realized we know its position on screen and this information can be used for various sound effects. One example are "positional" sound events. With a recent PulseAudio/libcanberra setup the sound will be panned on the L/R axis depending on the window position -- if the window is on the left side of the screen the sound will come more out of the left speaker and if its on the right side out of the right speaker. Which is really useful to help visually handicapped people locate the source of the sound on the screen and for the rest of is a nice gimmick. ;-) The first thing gtk_dialog_run() does is basically call gtk_widget_show(), so I thought I'd simply move that a bit earlier and allow the location meta data to be gathered. > - one thing (that I can take care of myself if you are too busy now you showed > me the way) that would be nice would be to play the sound in the following > situations: > . a dummy session has taken place and brasero is about to start burning for > real > . after blanking/formatting (in brasero-burn-blank-dialog.c) has been performed It would probably make sense to add two new names to the sound-naming-spec for this: complete-media-burn-test (hmm, or can you think of a better name?) complete-media-format The latter could then also be used for things like devicekit-disk when formatting a HDD or USB key. If you agree then I'll add them to the official sound naming spec. (http://0pointer.de/public/sound-naming-spec.html) And of course, I am happy for every patch I don't have to write. You're probably much faster prepping the patch given that you know the code of brasero. So I'd be thankful if you added that! > You also seem to forget to play the sound when the first disc of a spanned > session has been burnt. Oh indeed. I wasn't aware of that feature... > I was not sure if these were valid cases or if they fit the specs so I wanted > to have your opinion. I think they are valid cases. Of course we shouldn't overdo things with sound effects. But I generally think having hooks like these for long-running operations is probably the part that is the least controversial. Also, having many hooks is good, if the sound theme designer believes that they are too many he can easily disable them in his sound theme. So in summary, if brasero would generate those three sound events at those four places this would be a very good thing to have!
I committed your patch to master (now again the unstable tree). Thanks again for it. (In reply to comment #2) > It would probably make sense to add two new names to the sound-naming-spec for > this: > > complete-media-burn-test (hmm, or can you think of a better name?) > > complete-media-format > > The latter could then also be used for things like devicekit-disk when > formatting a HDD or USB key. > > If you agree then I'll add them to the official sound naming spec. > (http://0pointer.de/public/sound-naming-spec.html) I'm fine with them. Let me know when they are in the spec so I can add them after blanking/formatting, dummy burns and disc spanning. > And of course, I am happy for every patch I don't have to write. You're > probably much faster prepping the patch given that you know the code of > brasero. So I'd be thankful if you added that! > I will ;). > I think they are valid cases. Of course we shouldn't overdo things with sound > effects. But I generally think having hooks like these for long-running > operations is probably the part that is the least controversial. Also, having > many hooks is good, if the sound theme designer believes that they are too many > he can easily disable them in his sound theme. > > So in summary, if brasero would generate those three sound events at those four > places this would be a very good thing to have! Great then, I'm waiting for your "good to go".
(In reply to comment #3) > I committed your patch to master (now again the unstable tree). Thanks again > for it. Thanks for commiting! > I'm fine with them. Let me know when they are in the spec so I can add them > after blanking/formatting, dummy burns and disc spanning. Done. The spec is now updated. As promised I added complete-media-burn-test and complete-media-format for you.
Thanks a lot. I just committed the 3 other sound notifications to master.