SUMMARY Customising system sounds in KDE does not apply these changes properly to non-KDE apps. Instead, non-KDE apps (e.g. Wine, Firefox) continue to use whatever sounds come from the non-customised Global Theme System Sounds theme. STEPS TO REPRODUCE 1. Go to Notifications in System Settings 2. Choose System Notifications 3. Set a custom sound (or turn off the sound) for e.g. Beep, Question 4. Trigger an action that causes a beep in a non-KDE application (e.g. run `wine regedit`, double-click to edit an entry which opens a modal dialogue, then try to click outside the dialogue, which triggers a beep; or, open multiple Firefox tabs and then try to close the window, which will cause it to play `dialog-question` when it prompts for confirmation) OBSERVED RESULT The sound from the theme in Global Theme System Sounds is used rather than the custom sound. EXPECTED RESULT The custom sound (or disabling of sound) from the Notifications settings is used. SOFTWARE/OS VERSIONS Operating System: Debian GNU/Linux 12 KDE Plasma Version: 6.2.5 KDE Frameworks Version: 6.10.0 Qt Version: 6.7.2 ADDITIONAL INFORMATION It seems like KDE probably needs to generate a custom sound theme when the system sounds are customised that can be passed by name to GTK, etc., instead of only updating the plasma_workspace.notifyrc?
If the other app has hardcoded sounds, there is nothing else we can do. There's only so much we should fiddle with third party applications.
(In reply to David Edmundson from comment #1) > If the other app has hardcoded sounds, there is nothing else we can do. > There's only so much we should fiddle with third party applications. To me, as a developer, “hardcoded” would mean these apps either have some string to a fixed file path or embed audio data directly, but Wine’s X11 driver just calls `XBell`, and GTK apps follow the XDG Sound Theme spec and are taking and using the sound theme that KDE is telling them to use (via gtkrc). I’m not sure yet what is going wrong with `XBell`, but when it comes to GTK, KDE just needs to create and give a different sound theme to GTK with the custom sounds. I understand how that last statement may seem weird/backwards since the way notification sound customisation works in KDE is by replacing XDG sound names with file paths, not the other way around, and there is not a 1:1 mapping between a notification type and an XDG sound. Still, there are enough clear mappings (beep, question, device plugged in, etc.), and a working implementation is so trivial, that it makes sense to me to do it. KDE could either write to the XDG-standard `__custom` dynamic theme, or it could write its own hidden theme used just for GTK integration and pass that name to gtkrc instead. Please let me know if anything I wrote is unclear, or if you believe I am mistaken about any of it. Maybe this is really undesired for some reason, but given how KDE 6 was already changed to improve sound theme integration with GTK, it seems like there is a desire to improve this experience. As an end-user, it was unexpected that my custom sounds weren’t applying. Once I understood what was going on, fixing it was trivial, but I’m a software engineer. Let me know your thoughts. Thanks!
(In reply to Colin S from comment #2) > I’m not sure yet what is going wrong with `XBell` OK, I finally figured it out. This is controlled through kaccess for some reason, so the setting to change this sound is via the “System Bell” in Accessibility. It is not hooked up to the Bell notification at all. The UX for system sounds seems not great to me at the moment, being split between a non-detail-view in Notifications, a detail view in Global Theme, and a detail view in Accessibility, without any cross-linking. I’m not sure if I should open a separate bug about this or not.