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 '<'. > > > > 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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
