Notifications system discussion

[Christian Hammond]

On Tue, Aug 10, 2004 at 11:17:58AM +0200, Olivier Goffart wrote:
> Le Mardi 10 Ao?t 2004 09:48, Christian Hammond a ?crit?:
> > There are some changes I want to make to the spec, which I would like
> > some discussion on first.
> 
> Maybe, to keep confusion away, you could avoid to use the term "notification" 
> in your specs which make think to knotify, but uses "passive popup" or 
> "message bubble" or whatever. :-)

It's still a notification though, is it not? "Passive popup" is a term
that kind of bugs me, and neither term are always appropriate for the
potential UI.  Say the person using an application that implements
this spec is blind. We're no longer talking passive popups, we're
talking text-to-speech. The user is still being notified, though.
Another example would be a console implementation. Yet another would
be a "smart" implementation that forwards emergency notifications to
an IM account or cell phone if you're away.

(This is also, btw, one reason why a spec is more useful than just an
implementation, to answer a question asked in another post.)

> > 2) I'd also like applications to send along a notification detail ID.
> >    The spec would define a number of standard notifications (which
> >    we'll no doubt be adding to quickly), and non-standard ones would
> >    use x-foo. This would allow the daemon to be more intelligent when
> >    it comes to filtering. Like, if you get a email notification from 
> >    two apps within a very short time, only process one of them.
> 
> Not sure this will be usefull.  the action on each popup will probably be 
> different. (what happen if you click on the popup)

We can't even guarantee completely that the UI can support such
actions. See the console one above.

The ID is just one extra string param, so it's not hurting anything.
However, it would be useful for duplicate filtering, logging, etc.

> > If we have an application name and type ID, we could do per-type
> > customization. The one thing, though, is that you'd only be able to
> > customize notifications that have already been seen, but
> > (theoretically, depending on the daemon, again) a global customization
> > would suffice normally anyway. So you could set all mail notifications
> > to just play a sound, and all buddy notifications from a specific IM
> > client to appear in a bubble. Or whatever.
> 
> Here I do not agree.
> This is the job of KNotify to configure per notifications. So it's up to the 
> client (KNotify is the client for KDE applications)  to let configure.

It was just an example of what *could* be done with the information,
to satisfy those who want to customize every notification.

> Or do you want finaly to reach something more complex like KNotify. (Mike 
> doesn't seems to be verry for it)

No. The spec's simplicity would remain with this change. That was just
a possibility for an implementation in a UI. We're not dictating what
the UI can or cannot do.

> My idea was your specs just to popup a message around the systemtray.

The normal UI would, yes. I try to think about what people might use
it for, and plan around that, while keeping it simple enough where
it's not a kitchen sink or dependent on a bunch of things.

A specification that is simple and easy to use is not necessarily as
limited as I think some may think. We're sending the information about
a notification. The UI can do what it likes with this. As I said
above, for important notifications, such as "A virus was detected" or
"Such and such drive is out of space" or "Wild elephants made out with
your credit cards," the UI could be more intelligent and contact your
cell phone or some other device. The information could be displayed as
a popup, through text-to-speech, as a slide-over on the panel, as OSD
text, or anything. Sure, some potential UIs are limited in that you
cannot respond to the actions. Good applications would check the
client caps before doing anything, and it wouldn't be too hard for
some lib in KDE or GNOME to wrap this stuff and provide a dialog if
the UI doesn't support actions or something.

Christian

-- 
Christian Hammond         <>  The Galago Project
chipx86 at gnupdate.org      <>  http://galago.sourceforge.net/
   All constants are variables.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/xdg/attachments/20040810/daf797d6/attachment.pgp