KNotificationItem specification - first draft

[Marco Martin]

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

that's actually a good thing, the problem is that in windows it was so misused 
that it kinda becoma a dumpster, the target is kinda the same with the status 
property: if there is nothing to notify, hide it

> 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
> _______________________________________________
> xdg mailing list
> xdg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xdg


-- 
Marco Martin