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 '<'. > > > > 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 > [email protected] > http://lists.freedesktop.org/mailman/listinfo/xdg -- Marco Martin _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
