New notification system specs

[George Kiagiadakis]

Hi,

It's been a while since we decided that I should write this email, but
I nearly forgot about it. Sorry about that.

So, as we have discussed many times in the past, kde-telepathy is in
need of a better notification system. What we have now, KNotify, is
good in certain cases, but completely fails to serve some other cases.
In more detail:

What KNotify is good for:

* Handling notifications regarding text messages. KNotify can handle
any incoming or outgoing message and can do useful things with them,
like play a sound, display a popup which will autohide after a while
and some other less useful things. It can also distinguish between the
various sorts of messages (like incoming on inactive window, incoming
in group chat, incoming in group chat with highlight, incoming on
active window, outgoing, etc...) and let the user configure them
individually, without requiring much work from the developer (the
developer can just tell knotify that something has happened with this
context and knotify will find out if and how it will notify the user).
In general, I think that the overall design of KNotify is very well
suited to this use case (it was probably designed with this use case
as a basis in mind).

What KNotify can handle, but could do better:

* Showing notifications about possible connection errors or other
kinds of problems that MC reports. This is currently working, but it
could be improved. I hate it when there is a connection error and I
get a popup with an error message for every account I have configured.
It would be much nicer to let the notification system know that these
are just warning messages and configure it to make those less verbose.
For example it could just display a warning icon in the tray that can
be expanded to see the actual messages and autohide after a couple of
minutes.

What else do we need (or what KNotify is not good for):

The most pressing need that we have is a way to show persistent
notifications of the style "Foo is calling you: Accept/Hold/Reject".
This is needed for approving calls, tube channels and subscription
notifications. The requirements for this case are:

* Be able to show a persistent popup or other form of visual
notification (unlike KNotify where there is a Persistent flag, but the
frontend may choose to ignore it).
* Be able to have actions on this visual notification which must be
available in any case (unlike KNotify where the frontend may choose to
hide them).
* Be able to optionally play a sound.
* Be able to configure the sound to play constantly in loops while the
notification is active (eg. for the call-ui ringing sound) (KNotify
can't do that)
* Be able to kill the notification from the application (eg. for a
missed call, you don't want the notification to stay there forever)

I'm also thinking that we need a way to display missed calls / missed
tube invitations, probably as a persistent icon in the tray, but not
sure if this belongs in the notification system or if it should just
be a feature of the approver.

Other cool ideas:

The notification system could also profit from integration with
telepathy. For example, if my current status is "busy", I probably
don't want to be disturbed, so it would make sense for the
notification system to make things less verbose and for example
instead of a popup, show a flashing icon.


That's all I think. Ideas / comments welcome.

Regards,
George