After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 546989 - Use libcanberra for event sounds
Use libcanberra for event sounds
Status: RESOLVED OBSOLETE
Product: nautilus
Classification: Core
Component: general
unspecified
Other Linux
: Normal enhancement
: ---
Assigned To: Nautilus Maintainers
Nautilus Maintainers
: 594964 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2008-08-08 19:54 UTC by Luca Ferretti
Modified: 2021-06-18 15:15 UTC
See Also:
GNOME target: ---
GNOME version: 2.23/2.24


Attachments
Check for libcanberra-gtk availability and use it for "trash-empty" event (3.20 KB, patch)
2008-08-08 20:05 UTC, Luca Ferretti
needs-work Details | Review
Updated (3.20 KB, patch)
2008-08-08 21:57 UTC, Luca Ferretti
needs-work Details | Review
Lennart's patch (4.72 KB, patch)
2009-09-13 17:17 UTC, Lennart Poettering
needs-work Details | Review

Description Luca Ferretti 2008-08-08 19:54:32 UTC
libcamberra was approved as external dep for GNOME 2.24.

Could be interesting make Nautilus play some event sounds defined in fd.o Sound Naming Spec[1] such as "trash-empty" or "complete-copy" and other.

[1] 
http://www.freedesktop.org/wiki/Specifications/sound-theme-spec
Comment 1 Luca Ferretti 2008-08-08 19:55:55 UTC
Changed status to NEW according to this message[1] on mailing list

[1] http://mail.gnome.org/archives/nautilus-list/2008-August/msg00010.html
Comment 2 Luca Ferretti 2008-08-08 20:05:51 UTC
Created attachment 116183 [details] [review]
Check for libcanberra-gtk availability and use it for "trash-empty" event

A prelimary patch doing the follow:
 * check for libcanberra-gtk in configure and set useful macros
 * add a call to ca_context_play() (cut-and-paste for Epiphany) to play
   a the "trash-empty" sound

## Notes ##
The event sound is played when the action is started, not completed. According to Sound Naming Spec this event is filed under "Action" context and described as "The sound used when the user empties the trash." Events for completed tasks are filed under "Notification" context and there is no one related to trash or deletion. At least it seems to me the way to use this action...

I wasn't able to check if the patch actully works: it compiles, but currently I can't perform any action on panel due to a strange DBUS error (can't mount location - message did not receive a reply, timeout by message bus).

Also I like to check how audio preview is implemented in Audio capplet.
Comment 3 Luca Ferretti 2008-08-08 20:13:26 UTC
quote: can't perform any action on panel

sorry, it was "any action on trash"
Comment 4 Luca Ferretti 2008-08-08 20:16:25 UTC
Forgot to mention: I will away for the next weeks, starting from monday. Not sure I will have the time to produce a working patch before it...
Comment 5 A. Walton 2008-08-08 20:17:45 UTC
Tiny details:

+	$(CANBERRRA_GTK_CFLAGS)			\
Extra R.

+				 CA_PROP_EVENT_DESCRIPTION, _("Empty trash started"),

This is slightly misleading; "started" is usually accompanied by "finished". Perhaps "Emptying Trash" would be better.

Otherwise no objections from me.
Comment 6 Luca Ferretti 2008-08-08 21:57:54 UTC
Created attachment 116193 [details] [review]
Updated

Applied suggested changes, plus I can confirm that it works (a logout+login was helpful).
Comment 7 Luca Ferretti 2008-08-08 22:13:34 UTC
The following event sounds from naming spec could be useful in Nautilus (or, at least, there are related features in Nautilus):

## Notifications ##
 * complete-download (when a file completed downloading)
 * complete-copy (when a file completed copying)
 * search-results (when one or more search results are returned)
 * search-results-empty (when no search results are returned)
 * device-added (when a device has become available to the desktop, i.e. due to USB plugging)
 * device-removed (when a device has become unavailable to the desktop, i.e. due to USB unplug)

## Actions ## 
 * item-deleted (when a item is deleted)
 * file-trash (when a file or folder is sent to the trash)
 

Notes:
- "complete-download" and "complete-copy" are linked to the same sound in Audio capplet, see [1], and maybe there is no need to use "complete-download" for remote locations

- "device-*" are not strictly limitied to Nautilus managed devices, maybe those events should be managed at settings damemon level

- "search-*" could be interesting, but maybe related audio files are still not available 

- same for "item-deleted" and "file-trashed"

Conclusion:
By now the only reasonable even sound to implement in Nautilus is "complete-copy"

[1] http://svn.gnome.org/viewvc/gnome-control-center/trunk/capplets/sound/sound-theme-definition.h?view=markup
Comment 8 Christian Neumair 2008-08-09 10:39:42 UTC
Luca: Thanks for your efforts.

Regarding the patch:

The approach looks fine, but shouldn't the sound be played when the trash has been emptied, instead of when it is about to be empties? I.e. it's _("Emptied Trash"), rather than _("Emptying Trash").

I'm also not sure whether it makes sense to produce lots of translatable strings for CA_PROP_EVENT_DESCRIPTION, unless it's clear how it is used. A similar aspect is that we stuff the *translated* _("Nautilus File Manager") string to libcanberra - I do not see how it can be used in a sane manner if we use localized strings to identify applications.

CCing Lennart to get some feedback on this generic issue, Epiphany might have the same issues. It's important that we now write down how these contextual strings are used, whether a localized string should be provided or not (or an unlocalized one, with libcanberra knowing our gettextdomain). Maybe an application ID that can be looked up in the desktop dir should be used instead?

I'm not sure whether libcanberra is thread safe, and you are calling it from a worker thread. You should call it in the main thread (i.e. in a g_io_scheduler_job_send_to_mainloop_async handler, like empty_trash_job_done).

Marking patch as needs-work.
Comment 9 Lennart Poettering 2008-08-14 20:08:13 UTC
(In reply to comment #8)
> Luca: Thanks for your efforts.
> 
> Regarding the patch:
> 
> The approach looks fine, but shouldn't the sound be played when the trash has
> been emptied, instead of when it is about to be empties? I.e. it's _("Emptied
> Trash"), rather than _("Emptying Trash").
> 
> I'm also not sure whether it makes sense to produce lots of translatable
> strings for CA_PROP_EVENT_DESCRIPTION, unless it's clear how it is used. A
> similar aspect is that we stuff the *translated* _("Nautilus File Manager")
> string to libcanberra - I do not see how it can be used in a sane manner if we
> use localized strings to identify applications.

The PA volume control shows these strings. Eventually they might also be used  for a11y purposes.

> CCing Lennart to get some feedback on this generic issue, Epiphany might have
> the same issues. It's important that we now write down how these contextual
> strings are used, whether a localized string should be provided or not (or an
> unlocalized one, with libcanberra knowing our gettextdomain). Maybe an
> application ID that can be looked up in the desktop dir should be used instead?

CA_PROP_EVENT_DESCRIPTION is intended to be human-readable, and hence be translated on the client side. Events are identified by CA_PROP_EVENT_ID which is a non-translated ID string as defined in the sound naming spec. CA_PROP_EVENT_DESCRIPTION is ideally more than just a mapping for CA_PROP_EVENT_ID. I.e. it would be good if it would really explain what is going on: "File foobar finished downloading" instead of just "File finished downloading".

In short: the value for CA_PROP_EVENT_DESCRIPTION should usually be enclosed in _(), the value for CA_PROP_EVENT_ID not.

I have now added a few notes to the canberra docs to make that clear.

CA_PROP_APPLICATION_ID is similar in purpose to CA_PROP_EVENT_ID, and should be set to a string like "org.gnome.Nautilus". It's non-localized and should help policy enforcers to identify the program properly. CA_PROP_APPLICATION_NAME otoh is a human readable string and should be translated, if applicable. (i.e. translating "Microsoft Word" doesn't make too much sense, but translating "My little Hello World Application" does).

> I'm not sure whether libcanberra is thread safe, and you are calling it from a
> worker thread. You should call it in the main thread (i.e. in a
> g_io_scheduler_job_send_to_mainloop_async handler, like empty_trash_job_done).

libcanberra is thread safe.
Comment 10 Lennart Poettering 2009-09-13 17:00:51 UTC
*** Bug 594964 has been marked as a duplicate of this bug. ***
Comment 11 Lennart Poettering 2009-09-13 17:11:55 UTC
Hmm, forgetting that this bug (and patch) already existed and I actually had commented on this bug a year ago I prepped a new patch, which I atatched to 594964. Will now attach here too.

In contrast to the original patch posted here mine covers empty-trash, item-deleted and file-trashed. More importantly however, it handles the threaded file operation logic properly: while libcanberra is thread-safe gtk is not. That means that ca_gtk_xxx functions should only be called in a context where it is safe to call gtk_xxx functions, while the other ca_xxx functions can be called everywhere. To accomodate for that my patch calls ca_gtk_xxx functions from the main thread only, in preparation for the later actual ca_context_play_full() call which is triggered from the IO thread.

My patch does not cover device-xxx, search-xxx and complete-download/complete-copy sound events. (Please note that I think that complete-download should probably not be used in the context of a file manager. It's more something for something like epiphany or other software where the job of downloading is actually directly presented as "downloading")
Comment 12 Lennart Poettering 2009-09-13 17:17:26 UTC
Created attachment 143109 [details] [review]
Lennart's patch
Comment 13 Cosimo Cecchi 2009-10-07 15:40:38 UTC
Comment on attachment 143109 [details] [review]
Lennart's patch

> static void
>+prepare_sound (CommonJob *common,
>+	       GtkWidget *widget)

Is there any reason why you don't just play the sound after the file operation has ended (i.e. in delete_job_done() or empty_trash_job_done())?
Those are guaranteed to be called from the main thread; also, I think it's better to play the sound after the operation has been successfully completed, as otherwise there could be some error dialogs in between, which could be confusing.
Comment 14 Lennart Poettering 2009-10-07 16:55:34 UTC
(In reply to comment #13)

> Is there any reason why you don't just play the sound after the file operation
> has ended (i.e. in delete_job_done() or empty_trash_job_done())?
> Those are guaranteed to be called from the main thread; also, I think it's
> better to play the sound after the operation has been successfully completed,
> as otherwise there could be some error dialogs in between, which could be
> confusing.

I am not convinced. Those sounds should accompany the deletion/emptying the trash, they are not completion sounds. 

i.e. when you empty the trash the sound for it (paper being crumpeled) should play while you are trashing, not 10s later when the operation is completed, I think. In fact the paper-being-crumpeled sound is a pretty well known sound on other operating systems as accompanying the trashing and I'd find it weird if we did it differently on Linux.

Also, completion sounds in the sound naming spec are all prefixed with complete-xxx, and these two sounds are not, so if you really want only completion sounds then we need to introduce new sounds for this.
Comment 15 Luca Ferretti 2009-10-07 17:17:36 UTC
(In reply to comment #14)
> 
> I am not convinced. Those sounds should accompany the deletion/emptying the
> trash, they are not completion sounds. 

I agree with Lennart. But, if so, could be useful provide a better name/description in Sound Naming Spec. Currently we have:

trash-empty	The sound used when the user empties the trash.
item-deleted	The sound used when a item is deleted.
file-trash	The sound used when a file or folder is sent to the trash. 

We could rename sound names using -ing and/or we could update the description to something like "The sound used when the system is going to empty the trash"
Comment 16 Cosimo Cecchi 2009-10-07 18:10:04 UTC
While I might agree with your rationale when we're talking about emptying the trash, I'm not sure I agree for the other two cases you mention here (file trashed and file deleted), as the action could not be possible to accomplish (there could be an error in between).
The issue is if we also e.g. play a sound for error dialogs, you get two sounds at the same time, which is just confusing IMHO.
Comment 17 Lennart Poettering 2009-10-12 19:26:33 UTC
(In reply to comment #15)
> (In reply to comment #14)
> > 
> > I am not convinced. Those sounds should accompany the deletion/emptying the
> > trash, they are not completion sounds. 
> 
> I agree with Lennart. But, if so, could be useful provide a better
> name/description in Sound Naming Spec. Currently we have:
> 
> trash-empty    The sound used when the user empties the trash.
> item-deleted    The sound used when a item is deleted.
> file-trash    The sound used when a file or folder is sent to the trash. 
> 
> We could rename sound names using -ing and/or we could update the description
> to something like "The sound used when the system is going to empty the trash"

Hmm, fixing the description certainly makes sense. However, changing the name I am not sure. I'd rather say that those sounds that are prefixed with "complete-xxx" should be considered completion shounds, while the others should be sounds that accompany the action the user tirggered.
Comment 18 Lennart Poettering 2009-10-12 19:35:41 UTC
(In reply to comment #16)
> While I might agree with your rationale when we're talking about emptying the
> trash, I'm not sure I agree for the other two cases you mention here (file
> trashed and file deleted), as the action could not be possible to accomplish
> (there could be an error in between).
> The issue is if we also e.g. play a sound for error dialogs, you get two sounds
> at the same time, which is just confusing IMHO.

I generally think that completion sounds only make sense for long-running operations. If they are not long-running, then making a sound at all is probably misguided, since it's just too much. Now, some operations (such as "burning a CD") are by definition long-running. However, others are not necessarily, i.e. copying or deleting a file. Might be fast for some files, and slow for others.

So, here's how I like to see these things implemented in the long run: 1) play an event sound at the beginning of an operation, if defined in the theme and it is an operation directly triggered by the user. 2) play an event sound at the end of an operation, if defined in the theme, and at least $TIMEOUT seconds passed since the operation is started. And of course the starting sound should be shorter than $TIMEOUT, so that you never hear both sounds at the same time. This latter mechanism is not unlike how the showing of a copy-progress dialog is handled, in fact this should probably tied together very closely as in "never do a completion sound if you haven't shown a progress bar before".

If we do this, then we do two things: we give the user immediate feedback on the operations he did. This would fall under the broader term "input feedback". And we notify him when things completed. This would fall under "completion feedback".

Now the patch I prepped you could see as implementing "input feedback" for the three operations it covers. Adding "completion feedback" is then an additional step.
Comment 19 Lennart Poettering 2009-10-12 19:42:48 UTC
Oh, and I guess I should add a paragraph or two about this completion/timeout logic to the specification, so that this implemented in the same scheme across various applications.
Comment 20 André Klapper 2021-06-18 15:15:03 UTC
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version of Files (nautilus), then please follow
  https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines
and create a new ticket at
  https://gitlab.gnome.org/GNOME/nautilus/-/issues/

Thank you for your understanding and your help.