GNOME Bugzilla – Bug 537905
Mousing over an audio file on the desktop should not preview it.
Last modified: 2011-09-27 02:27:43 UTC
Reported here: https://bugs.edge.launchpad.net/ubuntu/+source/nautilus/+bug/237975 "I was working on one desktop when I suddenly heard music playing. Thinking it was a Flash video somewhere in Firefox, I switched desktops using the keyboard and it stopped playing. I switched back and it started playing again. After a minute of this back and forth I noticed that my mouse was hovering over an mp3 file on the desktop. While the audio preview is a useful feature in nautilus windows, I'm not sure it makes sense for the desktop."
I'm going to second this with some additional comments: 1) What value do audio previews serve? Most users will "test" a file by opening it. 2) If we do decide to continue with the preview, we need to make it very clear that an audio preview is playing and how to stop it (eg with a tooltip) 3) There is potential for harm here (playing music without being asked to during class/meeting, etc). This is especially true with audio files on the desktop. 4) We should never play an audio file with preview if it's already playing somewhere else. A common case of this is when I right click a file, tell it to open (or even queue) in my media player but leave my mouse nearby. The file will start playing, and also start previewing, leading to a very confusing double-sound.
The icon changes, so it's quite clear that audio is previewed. > 1) What value do audio previews serve? Most users will "test" a file by > opening it. Then simply disable it.
The icon changes on mouseover, not when the actual preview starts.
I think this audio preview is weird and confusing feature. I initially mentioned that the new Pusleaudio server is broken as I experienced some audio files are playing twice and/or unexpectedly when I was browsing my mp3 files. I realized that it is actually a Nautilus feature after several *months*. Please remove the feature, nobody will miss it, I guess.
I personally know at least two of my friends who would miss the feature, so "I guess nobody will miss it" is wrong. And you can always ask your distribution to turn it off by default.
I've seen this affect several people now, and I'm quite convinced that the icon change is absolutely not enough. It's a small, hard to notice icon, it doesn't appear as soon as the audio starts, and most importantly it's not clear whether it means "I will start playing sound in a second" or "click here to play sound". Many users would expect the latter, since they're about to open an audio file and clicking is what normally makes it play sound. At the very least, we should notify the user with some text somewhere, such as by using libnotify.
Instead of requiring people to choose between no audio previews and sometimes-unwanted audio previews, one possibility would be to make the audio previews take a bit more effort to trigger. For example, require a keypress in addition to hovering the mouse.
mpt makes a very good point actually. What if previews occured via a click on the little speaker icon? Once the preview started it could then animate to indicate a preview is going on rather than the file being opened somewhere in the background.
the long term plans for preview is to have a preview pane, when we get this the hover-preview functionallity for audio files will be moved to that and require some explicit click to play.
I actually find audio preview a very nice feature, I like it that way, I used even to show it to my friends to impress them :) this certainly isn't a bug for me.
*** Bug 533153 has been marked as a duplicate of this bug. ***
The only possible use I can think of for this feature is to help differentiate between sound files that have useless file names, but those situations are relatively rare and adequately served by existing media players. The current icon change - the display of the note in a speech bubble - is not good feedback, since the change in visual state does not coincide with audio playback (the latter is delayed).
Bug reorganisation.
*** Bug 131374 has been marked as a duplicate of this bug. ***
Posting the text from duplicate bug 131374 because it's not obvious that it's covered here: " Johan Walles [reporter] 2004-01-13 21:39:33 UTC Currently, if I preview an audio file (I'm thinking music), and I accidentally move my mouse pointer off the icon and then back in, the audio file starts playing from the beginning. This is annoying. To resolve this, I'd like the audio file preview to work like this: 1. If I move my mouse pointer onto an audio file: 1.1 If another audio file is being previewed, that one is stopped. 1.2 If this audio file is being previewed, the volume is reset to normal. 1.3 If nothing is playing at this point, the current audio file starts playing. 2. If I move my mouse pointer off the audio file, the volume starts fading towards zero at a suitably slow pace (5 seconds to silence?). That way, I could still preview several audio files by moving between them, just as I can today. I also would have a better way of not accidentally starting songs over again from the beginning when I don't want to. "
Not an issue anymore now that we dropped the previewer in favour of Sushi.
(In reply to comment #16) > Not an issue anymore now that we dropped the previewer in favour of Sushi. you just dropped it ? without any formal alternative... do you know that we are Gnome users ?
(In reply to comment #17) > you just dropped it ? without any formal alternative... do you know that we are > Gnome users ? There is a formal alternative in GNOME 3.2, called sushi. You can activate the preview by pressing spacebar on any file in any view. See https://live.gnome.org/ThreePointOne/Features/FilePreviewing and http://blogs.gnome.org/cosimoc/2011/04/29/sushi/ for more details.