Base

The basic stuff did not really change from KDE3. The event description file has just changed a bit for readability. I've let the event() function for convenience, although there is one more readable API using several function, as it seems the policy in KDE4 API. I've made some examples to show the difference and how to port.

Actions

So it is now possible to add one or several action on the notification. KNotify Popup Example, when a contact goes on-line, the user may want to chat with it. When we receive a message, of course we want to read it.

The way to do this is pretty simple, look this example inspired from Kopete.

 KNotification *notify=new KNotification("new_message");
 notify->setText(i18n("<qt>You received a new message from <em>%1</em></qt>") , message->from() );
 notify->setActions( i18n("View,Ignore").split(',') );
 connect(notify,SIGNAL(action1Activated()), message , SLOT(read()) );
 connect(notify,SIGNAL(action2Activated()), message , SLOT(ignore()) );
 notify->sendEvent();

Persistant Notifications

Another novelty is the possibility to have persistant popup, which only get closed when the notification is finished.

There are indeed two kind of notifications, those that are just a single shot event (typically, when a contact goes on-line, or a window get minimised) and more persistant notification which are valid until the user performs a specific action. Example, the new email notification may stay alive until the email has been read.

Again, that's really simple. just pass the KNotification::Persistant flag in the constructor, and don't forget to call notification->close() when the notification is finished. So you need to keep a pointer to the KNotification object.

It's also possible, if you keep the pointer, to modify the text of the popup, or re-emit the notification (eg. If new mails has been received we can use the same popup)

Contexts

Contexts is a novelty I'm proud about. It allows to the user to configure differently the notification depending some contexts. For example, in Kopete, this will be used to let choose another sound for a particular contact or group of contact. [1]

You first have to define some contexts name. In the case of Kopete, they are contact and group. [2] And before emitting the notification you just need to add context to it

notification->addContext( "contact" , message->from()->contactId() );
foreach(QString group , message->from()->groups())
     notification->addContext( "group" , group );

You have to add a Context key in the description file in order to let KNotify know which event are suitable for the given context. So configuration of notifications for a context may be done very easily also. In the property dialog, add a KNotifyConfigWidget using the following code

notifyWidget = new KNotifyConfigWidget( parent );
notifyWidget->setApplication(QString::null , "contact" , contact->contactId() );

You can see the result on this screenshot of the meta-contact property dialog . I know this looks pretty ugly, but remember it's just a technology preview, and I have not worked on the UI now. example of metacontact property

One of my plan is to make this also configurable from the global configure notifications panel, although that has not been coded yet.

Future

With this powerfull API, almost everything is possible. I've also constructed the daemon in a way that would eventually allow plugins later. But that API is not finished

I have also planed to magically handle the widget, by automatically raising a given widget, or closing the notification if the widget got the focus. Anyway, I don't know if the benefit is worth and I will maybe remove that API.

So I still need to do a great configuration dialog that present all options in a usable way. Hint from usability people are welcome.

And lot of cool possible stuff may be added:

  • replay the sound which tell you that we have a new mail every minutes until the mail has been read;
  • to specify if the popup has to stay or to be closed after a timeout;
  • to make blink a LED (eg. the scroll lock one);
  • have different beautiful kind of popup or balloon
  • ...

Of course, it need to comes with good defaults.

I'm listening to wish or hints.

Notes

[1] It was already possible in KDE3.5, but the code was very specific to Kopete, and not as powerfull as now.

[2] there is also a class context which is used by the Highlight plug-in, which may gives some classes to a messages if it contains some words.