On January 18, 2010, you wrote: > On 01/18/2010 03:12 PM, Aaron J. Seigo wrote: > >> Also, you need to give *some* indication of what this is for. Eg, > >> currently it could mean anything from "Please raise the indicated window > >> if the user clicks on the status item" to "Please hide the indicated > >> window if the user clicks on the status item". > > > > yes, that's up to the visualization. the point isn't to state what is > > done with the information, just to make that information reliably > > available. > > Let me try this again. Suppose you have: > > - KDE implementation: If WindowId is set, then raise that window to > the top if the user clicks on the status icon. > > - GNOME implementation: If WindowId is set, then *destroy* that > window if the user clicks on the status icon. > > You are saying this is perfectly legitimate and StatusNotifierIcons are > expected to cope with it?
yes. ignoring that the example given is a bit absurd, it is completely within the realm of possibility. > > i'm afraid that you are missing one of the primary points of this > > specification, which is that the visualization is in control of > > presentation. the visualization may instead play a sound, for instance; > > showing the attention icon in the case of an audio-only system (for > > sight impaired usage or for systems that simply don't have a visual > > output system) would be a bit silly, no? > > If audio-only systems were actually a first-class use case, then this is > not the spec you would have come up with. i never said it was a first-class use case. it's a possible use case, and one that we kept in mind as we went. the primary (or "first class", if you wish) use case is a visual representation since that's the status quo and likely to be the most common going forward simply due to issue of utility. so the spec certainly has a lot of visually oriented information in it, but it's also possible to build an audio-only analog with it. which is pretty neat and even useful. (i do think that if/when someone does such a thing, we may find ourselves with requests to augment the spec with audio hints as well; we'll cross that bridge when we come to it, though, and the non-pixmap related information may be enough in any case) > Having the visualization be in control of presentation is great, but you > need to give the app authors *something*. we give app developers a way to export a set of data. that's precisely the extent of we intend to do. what do you feel the app authors need that more than that? > Right now, the spec basically > says "here are some methods you can call, but there's no way of knowing > what will happen when you do". An application can't use > StatusNotifierIcon for any part of its UI that it actually cares about, > because it's possible that the StatusNotifierHost will ignore exactly > the parts of the spec that are the most critical to the app. yes, that would be the desired effect of encouraging application developers to stop abusing the system tray for things it really isn't meant for while simultaneously making it impossible to offer alternatives. from the perspective of the people who work on the desktop shell, if you rely on behaviour that isn't in that spec, you, as an app developer, are doing it wrong. i can understand why app developers want to abuse the system tray, but it is abuse and it leads to untenable situations for our users. we are not here to enable poor results, even if app developers are used to it being otherwise :) > And so the > StatusNotifierIcon would have to be entirely redundant with > functionality that was also provided elsewhere. can you provide concrete use cases? otherwise there is no way to actually discuss this point. > In the current (XEMBED) system, the app has all of the control, and the > tray is screwed, which sucks for the tray (and by extension, the > desktop). But flipping things around so that the apps are screwed > instead isn't an improvement. i have to disagree; the application is in complete control over the data that is represented. which is what it should have control over. the application is not "screwed" in any way similar to the way the xembed system represents. this is about taking the parts of the system that belong in the desktop shell and putting them there and the parts of the system that belong in the app and keeping them there. > We need (IMHO) a spec that makes a good > set of guarantees to *both* sides. which is what we've tried to do; if you can provide concrete use cases that aren't serviced, that would be most helpful. and yes, some uses of the system tray today are unacceptable abuses and we have zero intention of making the new spec encourage such behavior in future. the spec is already more complex than it "needs" to be to ensure we capture as much of the form and function of the system tray as we know it, but it is not intended to be a 1:1 clone of it. -- 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 _______________________________________________ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg