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? >> 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 7. Markup 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. 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 '<'. 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. 8. Icons You should also explicitly state the byte order of the image-data. Is it ARGB, RGBA? is it endian-independent? Aurelien _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel