Desktop Notifications Spec 0.3

[Lubos Lunak]

On Friday 24 of September 2004 11:27, Mike Hearn wrote:
> > > - Why not do it client side (seeing as apps *already* play sounds async
> > >   with app specific config ui)
> >
> >  - Only some apps already play sounds.
> >  - The client won't know when the notification is displayed
>
> I guess the spec is a bit vague w.r.t this - the assumption is that it's
> displayed as soon as the server can process the Notify request. We
> should perhaps state that explicitly.

 Does that mean there would be no possibility to delay and queue the 
notifications e.g. while playing a game or being in a don't-disturb mood for 
some other reason?

>
> >  - There's no guarantee that the notification will be displayed on the
> >    same physical machine as the notification.
>
> I guess you meant client. Network transparent audio is a different
> matter that needs to be solved anyway, but it's not the place of this
> spec to do so.

 But it would be certainly a nice bonus if it did so.

>
> > > - What formats are supported?
> >
> >  - My personal preference would be to only permit sound to be played
> >    by the notification server, based on the configuration of the
> >    notification server for the event type, *not* the app's choice of
> >    sound file.
>
> Well, the spec doesn't need to be changed then as this is an
> implementation detail. The only problem would be if the client decided
> to do a custom sound as well, in which case they'd overlap. We could
> probably put something in the spec telling clients not to play sounds
> themselves though.
>
> > Other core issues with sound include:
> >  - How do I disable/re-enable all sounds related to notifications
> >    quickly and easily, without muting the DVD I'm playing?
> >    (Unilateral configuration)
>
> I think this is a matter for a different spec. It's more a generic issue
> ... as I said, clients are free to do distracting things that aren't
> notifications and already do so today (think gaim popping up when
> somebody sends you a message).

 Hmm. On my desktop nothing gets in the way of the thing I'm working on right 
at the moment (unless there's a bug of course). New windows from inactive 
applications are not allowed by the window manager to get in the way, my 
media player doesn't just randomly start playing sounds,etc. So the only 
thing I see is whatever I'm working on, applets in the panel, and 
notifications about things happening in the background.

>
> >  - How do I ensure that gaim and gabber and kopete all make the same
> >    sound when a contact comes online?
> >    (Uniformity betweens applications)
>
> I think that's again a matter for a different spec, sound theming or such.
>
> >  - How do you synchronise the appearance of the notification with the
> >    playing of the sound?
> >
> > (Noting that the spec doesn't guarantee that the notification will be
> > displayed, nor does it guarantee even if it is displayed that it will
> > happen immediately the application requests it)
>
> Well, I think this should be fixed in the spec :)

 I find those to be desired features (or at least the ability to do so), so 
I'd consider your fixing of this in the spec to actually break it. Why should 
the notification be definitely always shown immediately?

>
> > By including sound in the server, rather than the client, you also allow
> > the server (or user) to have sounds for events where the application
> > author(s) didn't feel need to play sounds, but which the user would like
> > to hear sounds for.
>
> I'd say that's a bug in the app, but perhaps the best way to solve this
> is simply to say that clients shouldn't play sounds for notifications
> themselves. That way, the server implementation is free to do what they
> want.

 Cool. Let's follow this logic a bit longer, and say clients also shouldn't do 
other kinds of notifications (and again, the server implementation is free to 
do whatever it wants). This now of course reduces the job of apps to do only 
"hey, notification server, notify about this". Kinda reminds me of KNotify.

>
> > Another reason is that of reducing application complexity: by
> > abstracting the sound to the server you reduce the complexity of each
> > application - notifying the user of an event simply involves invoking a
> > D-BUS call, rather checking the user's sound preferences and possibly
> > playing a sound.
>
> I think this is probably better taken care of also by a sound theming spec.
>
> > Equally it reduces the complexity of the preferences dialog for each
> > application, although that's probably of more interest to GNOMitEs than
> > KDErs.
>
> If you assume sounds have to be configurable then it just moves that
> complexity somewhere else rather than reducing it.

 But it moves the complexity to one server from a zillion of applications. And 
of course, nobody forces your specific server implementation to be 
configurable or have sounds :).

>
> > The other reason is that sound is offensive.  It's invasive in that it
> > impacts on your senses even if you're not looking at the screen.  It can
> > be distracting and anything which increases the complexity or the
> > difficulty or reduces the accessibillity of a users' configuration of
> > the noises their computer makes is a Bad Thing(TM), IMNSHO.
>
> All the more reason for a "don't disturb me" spec, I think.

 But the only thing that can disturb are notifications! Applications usually 
don't just randomly start doing stuff, with the exception of the case when 
they want to notify the user about something (and broken or intentionally 
annoying apps of course, but you can't help that).

>
> > > Why not highlight the origin client side? What benefit does doing this
> > > in server provide? What about multiple screens? Z-Ordering?
> >
> > Assuming (in an X evironment) the same display, then the screen number
> > can be specified.  From there, it would be up to the server to ensure
> > the notification appeared on the correct monitor (e.g. in a Xinerama
> > setup).
> >
> > The most common circumstance I would envision is a drive or battery icon
> > in the system tray and (in the event that the implementation looks like
> > tigert's mockups) the tag would be positioned just above the icon in
> > question, although there are probably other ways in which it could be
> > used.
>
> Well, the thing with tigerts mockups is it's sort of hard to display
> multiple notifications at once like that, as they're all rooted at an
> icon somewhere on the panel (who says the user has a panel?).
>
> The basic/default presentation style I was aiming for is an MSN
> Messenger poptarts style, but others are certainly possible. I don't
> think it makes sense to add features that are only useful for one very
> particular style of presentation though. It could be a hint I guess.
>
> > > Yes, maybe. What are the use cases though?
> >
> > Cases where an application might use a "standard" notification or it
> > might use its own dialog, depending on the exact circumstances of the
> > event.  The purpose would be to record it as a "desktop event" in the
> > same way whether or not the notification server actually displayed it.
> >
> > TTFN,
>
> Hmm, well that widens the scope of the spec into a generic desktop
> events/logging/history type framework. Do we really want to go there?
>
> Also, some notifications may not make sense if the actions are removed
> from them (ie they'd be out of context). Hmm.

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l.lunak at suse.cz , l.lunak at kde.org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/