KNotificationItem specification - first draft

[Marco Martin]

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

not until 4.4.0 would mean to break and unbreak the whole trunk again but oh, 
well, got used to :)
but has to be -really- worth it and i don't see really better names right now, 
systemtray is even more problematic

> >> 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:
> > http://www.notmart.org/misc/notificationitem
>
> 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
whoops, corrected
>
> 7. Markup
>
> Supporting markup means opening a whole can of worms: you can't count on
yeah, i know :/
> 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.

i would love to dictate a really simple aspect,
i've seen that many aplications wrote their own tooltips to make really fancy 
stuff, since with this spec this wouldn't be possible anymore (again the 
problem is to know that those are icons and where it is) i don't think it's 
really realistic to ask everybody to drop that feature, we dropped some of 
them already that makes people not really happy...

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

i think i like more this way

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

yes. and maybe strip the not allowed tags?
how it was done in the Notification spec in the end?

> 8. Icons
>
> You should also explicitly state the byte order of the image-data. Is it
> ARGB, RGBA? is it endian-independent?
>
> Aurelien
At the moment, (should make it more clear in the spec) is ARGB and is not 
designed to be network transparent, so the endian should be the same of the 
machine for both the client and the server

-- 
Marco Martin