GNOME Bugzilla – Bug 793347
GNotification: Add support for custom sound provided by the theme
Last modified: 2018-05-24 20:13:12 UTC
Here is a branch that implements it: https://gitlab.gnome.org/GNOME/glib/commits/wip/tintou/gnotification-sound-theme Bug #788802 was marked as won't fix but it's clear that playing the sound in the app itself is a no-go as the goal here is to toggle on/off the notification sound in the notification settings panel. As many other things in the GNotification object, it is not required that the notification server will support this setting, nor that it will respect it in any way.
See also Bug #750926
My comment from https://bugzilla.gnome.org/show_bug.cgi?id=750926#c8 still stands: > How does this fit in with the latest changes to > notifications in gnome-shell? I want to avoid adding new APIs piecemeal to > GNotification, in case they don’t fit in with the overall long-term plan for > notifications in the shell. I don’t want to add (and have to maintain) API for this in GLib unless there’s a long-term plan for it to be supported in the shell or in some other widely-used notification backend. Please have a discussion on the mailing list, or somewhere else, with the designers about how/where to best solve your use case for notifications. I’d be happy to consider adding API to GLib for whatever they come up with as a solution. In the meantime, this is WONTFIX in GLib.
"sound-name" is already an explicitly listed hint in fd.o specs, it's also implemented in gnome-shell (and filtered through in the Settings Notifications panel), but some applications still call libcanberra by hand because of the missing support in GNotification. It would be much better for GNotification to support sounds explicitly, given that it's not possible to pass "hints" specific to a backend.
How to name the sounds is going to be the main problem, as we'd probably want the applications to be easily portable. https://bugzilla.gnome.org/show_bug.cgi?id=750926#c7 is the best example of why we'd want to support sounds. I could add: - making sure the display is on when playing the sound (so it plays when the speaker is inside a screen) - making it possible to switch the sound to a rumble for accessibility purposes - and generally, making those settings centralised in the Settings panel Right now, each application needs to reimplement their own sound settings, making global settings, or per-application settings in the Notifications panel, completely useless.
We plan to use this in elementary OS, as it's a hint listed in the notifications spec that we have implemented in Pantheon. https://developer.gnome.org/notification-spec/ From the design side, it makes sense to me that sounds would be handled along with notifications; as mentioned, it allows the notification server to make the final judgment with regards to if and when to actually play the sound.
Instead of exposing the entire sound-theme-spec we could easily just abstract over a few commonly used ones that are supported by OSX/Win32/fdo such as `G_NOTIFICATION_SOUND_NEWMESSAGE`.
(In reply to Patrick Griffis (tingping) from comment #6) > Instead of exposing the entire sound-theme-spec we could easily just > abstract over a few commonly used ones that are supported by OSX/Win32/fdo > such as `G_NOTIFICATION_SOUND_NEWMESSAGE`. If somebody has links to the equivalent Windows and macOS APIS, would be good to add here.
(In reply to Bastien Nocera from comment #7) > If somebody has links to the equivalent Windows and macOS APIS, would be > good to add here. Looks like OSX has one sound: https://developer.apple.com/documentation/foundation/nsusernotification/1412612-soundname?language=objc Windows has 20 or so: https://docs.microsoft.com/en-us/uwp/schemas/tiles/toastschema/element-audio
Oh sorry OSX has more sounds but they don't seem to be listed online: https://stackoverflow.com/questions/12267357/nsusernotification-with-custom-soundname#17493822
So, how do we move this forward ? I think there are some compelling arguments for supporting it. Comment #2 seems to indicate that Philipp wants to see sound-name supported in GNOME shell before merging this.
(In reply to Matthias Clasen from comment #10) > So, how do we move this forward ? I think there are some compelling > arguments for supporting it. Comment #2 seems to indicate that Philipp wants > to see sound-name supported in GNOME shell before merging this. We need to come up with a list of sound names which are generic enough to be usable on the 3 platforms we care about.
I think it would be better to just allow apps to specify a custom sound file in supported formats for a couple of reasons: * Popular cross platform apps, like Slack, that are already using custom sounds likely want to remain consistent with the sounds they use across platforms. Offering them theme sounds doesn't solve that problem. * Similarly some apps, like Skype, are using sounds as part of their branding. Offering them theme sounds doesn't solve this problem either. If an app uses a custom sound, the purpose of doing so is likely to specifically identify itself either in contrast to other installed apps or as part of their cross-platform branding. Offering a list of sounds might work for default/1st-party apps, but if other apps are using the same sounds, this defeats the purpose for 3rd-party apps and doesn't help us get to a world where users can choose to disable notification sounds at a global level.
I agree with Dan here; if apps are not allowed to use custom sounds, they will continue to implement sounds outside of the notification system, and the platform and users will not be in control of it at all. So effectively nothing will change. However, if apps are able to pass a custom sound to the notification system—much like how they can pass a custom icon/image—we have some hope of them doing so, and then sounds will be able to be controlled according to the user's settings and/or the platform defaults.
From what I've read OSX Notifications do not support custom sound paths. The Windows docs only says Windows Phone can play bundled files and even then only from uwp bundles which few Gtk applications would use even if it works on Windows.
Must Windows and macOS support these features to be able to bring them to GNOME and other FreeDesktop platforms? Windows does cover it in their UWP docs, which is for both desktop and mobile. I'm not sure about their other non-UWP desktop APIs, which it seems they consider to be "legacy" considering the new defaults in Windows 10 and the lack of documentation. https://docs.microsoft.com/en-us/windows/uwp/design/shell/tiles-and-notifications/custom-audio-on-toasts Android supports setting a sound via URI, and nearly every major app on Android uses this. https://developer.android.com/reference/android/app/NotificationChannel#setSound(android.net.Uri,%20android.media.AudioAttributes) According to the Apple Human Interface Guidelines, they support custom or built-in alert sounds. It's not clear which platforms this is for, but it covers at least iOS, watchOS, and tvOS from what I could find. https://developer.apple.com/carekit/human-interface-guidelines/user-interaction/notifications-and-badging/#designing-a-great-notification-experience This is a feature that major, modern platforms support and app developers will expect. Again, if it's not supported by GNotification, developers will continue to play sounds within their own apps which means there is a lack of control and consistency from the platform perspective. Features like Do Not Disturb are severely crippled by the lack of these features, since apps may have their notifications hidden, but continue to play their own custom sounds in the background outside of any sort of control.
(In reply to Cassidy James from comment #15) > Must Windows and macOS support these features to be able to bring them to > GNOME and other FreeDesktop platforms? Gio is a platform abstraction, while this is a relatively minor feature to not be portable it would be nice. > https://docs.microsoft.com/en-us/windows/uwp/design/shell/tiles-and-notifications/custom-audio-on-toasts Hmm, should be good enough. > This is a feature that major, modern platforms support and app developers > will expect. Again, if it's not supported by GNotification, developers will > continue to play sounds within their own apps which means there is a lack of > control and consistency from the platform perspective. Features like Do Not > Disturb are severely crippled by the lack of these features, since apps may > have their notifications hidden, but continue to play their own custom > sounds in the background outside of any sort of control. In the end I do agree. Maybe we can support both a few named sounds which Gio promises makes *some* sound on the 3 main platforms and then allow a custom one which is only guaranteed to work on Unix?
Yes, that would seem like a sane compromise. I would imagine playing a default sound would be better than playing nothing on unsupported platforms, but that's more an implementation detail.
(In reply to Daniel Fore from comment #12) > I think it would be better to just allow apps to specify a custom sound file > in supported formats for a couple of reasons: > > * Popular cross platform apps, like Slack, that are already using custom > sounds likely want to remain consistent with the sounds they use across > platforms. Offering them theme sounds doesn't solve that problem. > > * Similarly some apps, like Skype, are using sounds as part of their > branding. Offering them theme sounds doesn't solve this problem either. > > If an app uses a custom sound, the purpose of doing so is likely to > specifically identify itself either in contrast to other installed apps or > as part of their cross-platform branding. Offering a list of sounds might > work for default/1st-party apps, but if other apps are using the same > sounds, this defeats the purpose for 3rd-party apps and doesn't help us get > to a world where users can choose to disable notification sounds at a global > level. I don't think we should be supporting the compositor/notification daemon playing back sounds, as it's a possible security issue. It's unlikely that the notification daemon would have access to the application's data files anyway, so other methods would be needed for those cases. On iOS, for that Skype case you mention, callKit is used to do this within the application: https://developer.apple.com/documentation/callkit/cxproviderconfiguration As for Slack, they can carry on playing back sounds within the application. Helper functions that follow the notification sound settings should be provided however.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/1340.