KNotificationItem specification - first draft

[Aurélien Gâteau]

Aaron J. Seigo wrote:

> it's not too late in the sense that we have until 4.4.0 in January when we 
> become committed to it.
> 
> what we didn't like about "System Tray" is that it doesn't really say what the 
> point of it is. "System Tray" is "where those things appear" while 
> "Notification Item" says "what those things are supposed to be doing".

Agreed.
[snip]

> as for the root of the problem of "it's confusing", "notification area" is a 
> term used on a couple of platforms already, including the most widely used one 
> (Windows). it's not exactly a new term. in relation to notifications, those 
> things which pop up when an application asks to tell the user something, 
> actually relating these two things together semantically is a good thing IMHO: 
> they are both about pushing information to the user's attention and they 
> should probably coordinate in some fashion as well (e.g. in a visual 
> representation, it may make sense to have app notifications visually 
> associated with their notification item; possibly combine that with 
> notification item + task bar integration)

I believe it's called "Notification Area" on Windows because it is very 
strongly tied with Windows notifications: the MSDN states this:

"Does your program need to display a notification? If so, you /must/ use 
a notification area icon."
(http://msdn.microsoft.com/en-us/library/aa511448.aspx#rightui)

Since this spec aims to be desktop independent, whether notification 
bubbles and notification items should be visually grouped is an 
implementation detail. It should not be up to the spec to suggest this.

I am not that much into fancy names, but I thought about it a bit and 
came with those semi-lame ideas:

- AppSatellite
- SatelliteItem

>> 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
>> markup.
> 
> it's a simple subset of markup and is something that app developers routinely 
> ask for, at times even with quite valid use cases ;)

I would be interested in these use cases.

>> 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 '&lt;'.
> 
> yes, if the spec says "markup" then this would be implied.

It should be explicitly stated in the spec IMO.

>> or:
>> State that if an item wishes to use markup, then it must enclose the
>> whole text in a <markup> tag.
> 
> that would work as well. it's a small amount of overhead for not much pain. it 
> could also be that we look for the "<pre>" tag instead, and make markup the 
> default.

Doing it this way is not good. It can fail in the (admittedly rare) case 
where the plain text contains the closing tag.

> 
>> 8. Icons
>>
>> You should also explicitly state the byte order of the image-data. Is it
>> ARGB, RGBA?
> 
> ARGB.

Same thing, it should be explicitly mentioned in the spec. Together with 
endianess dependency or independency (note that Qt ARGB format is 
endianess dependent).

Aurelien