https://bugs.kde.org/show_bug.cgi?id=499031
--- Comment #2 from Colin S <bugs.kde....@zetafleet.com> --- (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! -- You are receiving this mail because: You are watching all bug changes.
