Aurélien Gâteau wrote: > We want to work with upstream developers to find > an agreement so that applications can display notifications in a > consistent way, regardless of which toolkit has been used.
Sounds great! FYI, I work on Xfce, and I'm the author/maintainer of xfce4-notifyd. > # Other issues/suggestions? 1. Passive vs. active notifications. I recall that notify-osd unilaterally decided that the 'actions' bit of the spec was Bad[tm] and that notifications should be entirely passive and not accept input. I disagree with this. Being able to interact with notifications is useful in the case where an app without a "normal" GUI (such as a wifi connection manager) wants input from the user but doesn't want to steal focus or block what's going on[1]. One might consider interactivity as an abuse of the concept of a "notification," but... who cares? If it's useful, we should attempt to support it if feasible. There's also the issue of supporting legacy notification bubbles from e.g. Win32 apps run via Wine, which often expect interactivity. 2. Minimum features. I'd say that some more features should be *required* in the notification daemon than currently are. As the Ubuntu spec notes, many (all?) all apps in the wild seem to assume support for anything notification-daemon supports, and not check the daemon's capabilities as they should. Some features cause trouble if they don't exist: 2a. If the notification daemon doesn't support body-markup, then, in theory, it should display body text in raw, unescaped form. Obviously, then, clients should only send plain text in that case, but most probably don't (since they don't check for the body-markup cap). I'd suggest requiring that all body text be html- and entity-escaped. The daemon can decide whether it wants to show the formatted text or strip the markup. 2b. Back to 'actions' again. If an application wants to be conformant, it should check for the 'actions' capability (which most probably don't do). Even if they *do* check for this, the app author will have to write a decent amount of custom code to handle both cases (e.g. falling back to a normal dialog box if the server doesn't support actions). There are two decent solutions to this: require 'actions' support, or handle the fallback case in libnotify (or in other desktop-specific client libraries). I'd push for the former. In general, I'd say support for features that only affect *presentation* (markup, image support, URL linking, etc.) is ok to be optional, but anything that affects *functionality* should be required. 3. The Ubuntu spec adds a 'sound-themed' hint, while we already have 'sound-file'. I'd suggest just overloading 'sound-file' to take either a sound theme name or a sound file. Implementations that only support a full path will simply fail to play it; no big deal. With 'overloading', implementations don't have to handle Yet Another Hint. Downside: apps wishing to provide a sound theme name plus a fallback sound file path won't be able to. Is that a big deal? (There's also the cosmetic question as to what "sound-themed" logically means. It should be something like "sound-name" or "themed-sound-name".) All I can think of for now... -brian [1] Yes, I know about non-focus-stealing windows... the problem with these is that they are poorly implemented across WMs: you can either use _NET_WM_USER_TIME, which all WMs may not support, or you can use the focus-on-map hint, which should be better supported. Using either method (especially focus-on-map), you can't be sure that the new window is actually brought to the front such that the window is visible to the user (even if unfocused). I suppose a solution to that might be _NET_WM_STATE_ABOVE -- not sure how suitable that is, or if it might be considered 'abuse' of the standard. _______________________________________________ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg