KNotificationItem specification - first draft

[Aaron J. Seigo]

(dropping the other two lists as CC's as one list should be enough for 
discussing this, and xdg is the most appropriate?)

On September 7, 2009, Aurélien Gâteau wrote:
> > 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?

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".

there's also the issue that we classes like QSystemTrayIcon and 
KSystemTrayIcon which complicates things further (as a Notification Item falls 
back to that SystemTrayIcon implementation)

then there's the "System Tray Protocol Specification" on freedesktop.org:

	http://standards.freedesktop.org/systemtray-spec/systemtray-spec-0.2.html

the two specs really have very little in common other than both can be used to 
make an icon appear in the panel.

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)

> 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 ;)
 
> 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.

> 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.

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

ARGB.

> is it endian-independent?



-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freedesktop.org/archives/xdg/attachments/20090907/fc8f0124/attachment.pgp