KNotificationItem specification - first draft

[Aaron J. Seigo]

On September 8, 2009, you wrote:
> Aaron J. Seigo wrote:

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

it doesn't suggest this, it just suggests that this technology is in the same 
category as "stuff that communicates application information to the user".
 
> I am not that much into fancy names, but I thought about it a bit and
> came with those semi-lame ideas:
> 
> - AppSatellite
> - SatelliteItem

i have no idea what those mean, and i doubt any developer would without 
consulting documentation. they also don't speak to the function/purpose: "what 
does a satellite do? why do i need one? what is it a satellite of?"

at least NotificationItem uses a well known term and speaks to what they do.

what you are looking for is a way to disambiguate between "notifications, the 
things that pop up in bubbles" and "notification items, which communicate 
status information and allow some basic user interaction", correct? so .. 
StatusNotificationItem? starts to get long. doesn't really speak to the 
interaction bits, but then neither does NotificationItem.

and i'm left wondering if this isn't solving a problem that doesn't really 
have any consequences as it currently stands? we haven't actually had any 
confusion to date, but then it hasn't been widely used either. it's not a 
user-facing issue, in any case, so the bar is not as high as usually required.
 
> >> 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.

providing visual emphasis for the significant parts of a message such as a 
file name or returned message text; enumerating lists of items ...
 
> >> 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.

fair enough ... this sounds very much like stating something remarkably 
obvious, but it can't hurt.
 
> >> 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.

how is that different from using <markup>? this just says that rich text is 
the default, and if you want plain text to use <pre> around your text.

or maybe a less hackish way to go about it all would be to add a bool member 
to the ToolTip structure that says whether or not this is markup or not.

in practice, i'm not sure how much this matters one way or the other. we've 
had rich text tooltips for a while now and there hasn't been any incidents 
with "but i wanted plain text only! the tooltip unexpectedly looks like crap 
now!"

so i'm not sure what the push back on allowing some basic formatting in 
messages is due to. there's a reason most document formats allow for more than 
plain text.
 
> >> 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.

sure; that can be added to the section describing the dbus data structure. i 
suppose the assumption was that "ARGB" means "ARGB" and note "RGBA" ;)

> Together with
> endianess dependency or independency (note that Qt ARGB format is
> endianess dependent).

correct.

-- 
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/20090908/10c990a5/attachment.pgp