KNotificationItem specification - first draft

Aurélien Gâteau aurelien.gateau at
Mon Sep 7 13:24:27 BST 2009

Marco Martin wrote:
> On Monday 07 September 2009, Aurélien Gâteau wrote:
>> Hi,
>> I am probably a bit late at this, but thought I would ask anyway.
>> Why did you choose the term "KNotificationItem"? I am afraid this is
>> going to cause confusion with the existing notification systems.
> the choice of the name has been a bit painful, it has gone trough several 
> renames.
> iirc this was chisen because in gnome and windows the systray is already 
> called notification area and we didn't want to confuse the current 
> implementation with the protocol, since the last goal is to remove some of the 
> icons from the system tray, probably representing the items of "application" 
> category in the taskbar, this would make the "SystemTray" term less meaningful

I understand the reasons, but I still think this is confusing. Is it too 
late to change the name, or can it still be brainstormed?

>> PS: To get more feedback about the spec, I suggest you generate an html
>> output of it and upload it somewhere.
> yeah, good idea, here it is:
Thanks for this!

Here are some corrections/suggestions:

3.3. Signals
3.3.1. NewTitle

I suggest reporting the new title as a signal parameter to avoid a 
round-trip from the host to the item to fetch the text.

4.1.4. RegisterNotificationHost

Wrong method name in the prototype

7. Markup

Supporting markup means opening a whole can of worms: you can't count on 
app developers to properly escape the content they send and you may end 
up with using heuristics to determine whether the '<' character is a 
single character or the beginning of a tag.

Since the content of tooltips aim to be short, I suggest not supporting 

If you think this is too restrictive, then I suggest to either:
State that everything is markup and a '<' character should *always* be 
escaped to '<'.

State that if an item wishes to use markup, then it must enclose the 
whole text in a <markup> tag.

In both cases you want to check the first implementations of 
NotificationHost strictly enforce these rules.

8. Icons

You should also explicitly state the byte order of the image-data. Is it 
ARGB, RGBA? is it endian-independent?


More information about the kde-core-devel mailing list