rjvbb added a comment.
> We probably lose the ability to play sound on Windows and Mac? Does libcanberra (still) require pulseaudio or can it work with different backends? It not, a move to using it exclusively for sound would get a big fat -1 from me. Pulseaudio is problematic on Mac and more alien than DBus; it simply shouldn't be required. (I have gripes with it on Linux too; too often I get the sound notifications way after the event simply because the PA daemon had been swapped out or otherwise unavailable.) > How does it work there normally? It works just fine with the gstreamer or libVLC backends. Building libVLC for 3rd party use is a bit of an adventure on Mac but I have made a MacPorts port for it. > (We could just make it do `QApplication::beep()` if a sound is configured :p) I proposed that once as a fallback for misconfigured alerts and caused knee-jerk reactions in certain reviewers who remembered the days of the PC tweeter beep... ... > - `LoopSound` also work but probably won't create uninterrupted playback anymore. But I have seen only one user of that in lxr which is some playground dialer app.. The Multimedia/Sound KCM has a few test buttons; do those work? IIUC KNotifications already has the logic for finding sound theme files, so if a lighter sound backend is required, why not use a truly cross-platform library like PortAudio? FWIW, using QSP for finding those theme files instead of some independent implementation has the advantage that they are expected in a QSP-compatible location. Or will have that advantage, the day a solution is found for working with the non-XDG QSP locations on Mac and MSWin. REPOSITORY R289 KNotifications REVISION DETAIL https://phabricator.kde.org/D14397 To: broulik, #frameworks, dfaure, davidedmundson, sitter, drosca, kfunk, rjvbb Cc: kde-frameworks-devel, michaelh, ngraham, bruns
