Desktop Notifications Spec 0.3
m.hearn at signal.QinetiQ.com
Wed Sep 22 16:22:41 EEST 2004
> So config UI for server is wrong, config UI for client is right? Why exactly?
Well, I said *requiring* it would be wrong. Anybody who implements the
spec is free to give their server a config UI if they want to
> There can be more good reasons to have sounds in the server othen that crappy
> kernel support. Apps wouldn't have to link against a dozen of audio libraries
> just to do beep.
If you take that view to the logical conclusion you end up with arts and
doing it all out of process, which has been tried and didn't seem to
work. A PlaySound() type API doesn't have to be heavy, it isn't in
Windows (and presumably the same is true of the mac).
> Or, perhaps more importantly, with KNotify I can disable all
> sounds by few clicks, and if somebody was bothered to implement KNotify
> profiles, I could change all notifications depending on situation just by
> switching profiles. With your way, the only reasonable way seems to be
> turning off the speakers.
> Actually, this makes a really good point. Let's say that we don't have this
> broken state of Linux audio, and I want to play a game, without being
> disturbed by any other sounds. With KNotify, that'd be simple. What would one
> do with your spec, given that turning off the speakers would kinda ruin the
> game, and turning off sound notifications in all apps would be a nightmare?
This is a good point. Presumably if you are playing a game, or some
other task which requires 100% attention, you don't want any
notifications at all. So, perhaps there should be some way for apps to
ask the server to suppress notifications.
Alternatively, maybe you could just say in the server "Is there a
fullscreen app running? If so, then don't do any notifications".
More information about the xdg