Desktop Notifications Spec 0.3

[Lars Hallberg]

Mike Hearn wrote:

>> I can see one more use for having sound in the notification spec.
>>
>> Stuff like 'new email', 'user foo enters chat' etc can be notifed 
>> with sound  and/or visual notification. Having sound and a option to 
>> tell that 'sound or notifikation is OK' in the spec make this 
>> costomisable in a central place, good for accessability! IE, For 
>> sound notifikations I want [ ] only sound if avalible, [ ] only 
>> popup, [ ] both.
>
>
> I agree with Christian that this is best dealt with by filtering on 
> type/urgency.

Thats probably good enuf. But if the app can optionally tell the name of 
the sound would be good, for stuff wher one want a diferent sound for 
some users joining a chat. Thats probably saner to config at the IM 
config level then in some 'global' config.

But the real problem with leving sound out, and even vorse, making it 
implementation specific, is that every app must figure out, depending on 
implementation of the notification service, if they shold play a sound 
themself or not. That will lead tho the common situation wher some stuff 
work togheter, and some dont, and newer ever everything works like it 
should, atlest without tveeking.

The cuestion to be put is, if You want sound for your notifikations - is 
the sound conseptualy part of the notifikation. I say Yes! And then it 
shuld be part of the spec, possably (but I don't think it's optimal or 
even good) only saying: The notifikation service shuld never ever play 
sounds!

I'm all for the unix paradigm 'do one thing, and do it well'. But that 
'one thing' shuld cover it's compleet consept - else You ask for headace!

> If the notification server has required config UI I think we might be 
> doing something wrong.

Don't think this require config UI, the service can pik one behavure 
hardcoded. *That* can be implementation specific. It might be required 
for accesability needs, but in that case it can be derevided from the 
desktops central accesability config!

>> Even without a notification history we gain that every app need not 
>> to detect if they can play sound. I some time shut down the sound 
>> server to use apps talking to sound device. If that automagicly made 
>> gaim notifikations visual it would be cool!
>
> I'd veto adding sound back in for such a reason. It's hacking around 
> the broken state of Linux audio (not all operating systems refuse to 
> do kernel-level mixing), and that problem is orthogonal to this.
>
> Applications should be able to play sounds whenever they like, we have 
> the technology to do this, now it's just a case of figuring out how we 
> want to do it and where.

I agre there... but I'm a bit pesemistic about this geting a 'cover all 
install case' solution anytime soon :-(

So, pragmaticly, we have to deal with it for a while more. That don't 
men we shuld design broken stuff to get around it. But a notification 
spec covering the complet consept of notifications is not broken, on the 
contrary!

/LaH