Re: comments on StatusNotifier spec
On 01/18/2010 05:24 PM, Aaron J. Seigo wrote: 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. How is it absurd? Both of those two behaviors are things that window managers do under certain circumstances, so neither is an intrinsically absurd behavior. And nothing in the spec suggests that either of those behaviors is either recommended or discouraged. So how is the implementer supposed to know that one of those two ideas is absurd? (Or are they both absurd? I don't even know.) Of course the idea that one implementation would do one thing and another would do the other is absurd, but that's exactly my point; the spec encourages this sort of absurdity. 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? Knowledge of what's going to happen with that data! If all they want to do is export data, they can use printf. 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. OK, you mentioned volume indicators in another email. So, presumably I would want to have a series of icons for different sound volumes, and some way of indicating muted. Let's say I want to indicate mute by overlaying a red X over the existing volume icon (so that the user can still see under the X whether the volume would be loud or quiet if he unmuted it). The seemingly-obvious way that the spec offers for doing this is to use OverlayIconName or OverlayIconPixmap. Now, the first problem is that I can't actually control *where* the overlay shows, so maybe the X will be drawn in the worst possible position, and make it impossible to see the important part of the underlying icon. But that's a minor problem compared to the fact that there is no guarantee that the visualization will show the overlay *at all*. And obviously I don't want it to be the case that with *some* StatusNotifierHosts, full volume and currently muted but previously full volume would look exactly the same. So this means I have to simply ignore OverlayIconName/OverlayIconPixmap and do something else instead. (Either precompose the overlaid icons and use a separate IconName/IconPixmap for each, or else not use an overlay to indicate mute.) I'm assuming your argument is something like but the tray may want to enforce strict restrictions on how icons look, so as to preserve a consistent visual style, etc etc etc. And that's a perfectly reasonable goal. But saying you can set this property, but sometimes it will be ignored is an awful way of implementing that goal, because from the application side, it translates to you can only use this property to display information that is *completely unimportant* to the user. (There isn't even any way for the application to *know* whether or not the overlay is being/will be displayed.) It would be better to simply remove the property entirely. And so on throughout the spec. As I understand what you have said, there is absolutely *nothing* you can do with the spec that is guaranteed to have any effect. The icon is not guaranteed to be shown, the urgency hint is not guaranteed to have an effect, the tooltip is not guaranteed to be shown, there's no guarantee you can Activate the item, etc. So how can an application author possibly use this spec? (Answer: by targeting a single desktop environment and assuming that the StatusNotifierHost will behave exactly like that desktop's StatusNotifierHost is known to behave. And in that case you don't need an FDO spec.) -- Dan ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: Proposing the StatusNotifier specification
On January 19, 2010, Giles Atkinson wrote: Do you have concrete examples? every app we looked at that puts an icon in the tray (and there are dozens) fits into one of the existing categories; in fact, that's how we came up with them. Yes, I do and it is not an isolated case, but an example of a reasonable class of applications: those that present foreign windows from another environment and wish to integrate them as smoothly as possible with the local environment. This class potentially includes remote graphics applications, VM hypervisors and emulators such as WINE. (At the edge of it are straightforward applications using X remote display, whose use of the replacement notification interface is blocked by the sole use of D-bus.) if this information is not known, then i'd suggest tagging them as ApplicationStatus since that's the best that can be done. as an implementation note, the Plasma widget that provides the system tray for plasma-desktop and plasma-netbook treats all xembed icons as ApplicationStatus since we can't introspect any additional information out of them. so in the case of no information available, we default to ApplicationStatus Applications in this class only have the information about their notification items that they get through the underlying foreign interfaces, and that is very unlikely to include anything that approximates the four categories. is there information in these systems that offers a categorization? if so, then we can work on harmonizing our categorizations with common practice elsewhere. if there is no category information, then i suggest using ApplicationStatus as a default fallback. That could be interpreted as meaning they are barred from this interface, that would be an incorrect interpretation. would it help if the entry for ApplicationStatus was extended from: ApplicationStatus: The item describes the status of a generic application, for instance the current state of a media player. to something like: ApplicationStatus: The item describes the status of a generic application, for instance the current state of a media player. In the case where the category of the item can not be known, such as when the item is being proxied from another incompatible or emulated system, ApplicationStatus can be used a sensible default fallback. ? but in practice the application developers will simply make them lie. if you can describe some use cases in which the developer will make the item lie (e.g. this is supposed to be a $FOO system tray entry on Windows, and when run through $COMPATIBILITY_LAYER it will likely end up appearing as $BAR instead) then we can work on this. On the subject of backward-compatibility you also wrote: ... older clients aren't ignored at all (at least if the host visualization (e.g. system tray), doesn't suck). the goal is to deprecate, and eventually get rid of, the old and broken xembed based system That is all very well, and what anyone might want to hear, but it is not what is in the specification. the specification does not require all visualizations to also support the xembed system. that is because not all visualizations will be system trays and the spec is not about the xembed system but a different system that provides far greater capability than the xembed system which sits aside the xembed system. i really do hope that we can phase out the xembed system in our own applications. whether we can do so for things like apps running through WINE is not a given; i think it's obvious that apps using the xembed system will be with us for many years to come. as such, it's only reasonable to expect that people who write system trays will include xembed support as well. it is not, however, in the scope of this specification to mandate how system tray wigets are written. the scope is to define how a visualization, which a system tray is one possible kind of, can work with applications using this d-bus based mechanism. As I have already mentioned, the specification is completely silent on compatibility with older clients, implying it is not an issue. The addition of a single sentence would fix that. if you could offer an example of the sentence you have in mind, that would be helpful. It is also silent on the motivation for the design (which still looks weak to me) and the semantics of the operations parameters, as Matthias has pointed out in another thread. the semantics of the operations as realized in a given visualization are not overly specified to purposefully allow for flexibility in the visualization. yes, there is an assumption here that those writing those visualizations aren't idiots and are able to do their job with a bare minimum of competency. i hope that isn't too much to ask. as for the motivation of the design, i agree that it is not obvious (as evidenced by these discussions). we will add a bit about the motivation for the design
Re: Proposing the StatusNotifier specification
On Tue, 2010-01-19 at 10:44 -0800, Aaron J. Seigo wrote: the semantics of the operations as realized in a given visualization are not overly specified to purposefully allow for flexibility in the visualization. yes, there is an assumption here that those writing those visualizations aren't idiots and are able to do their job with a bare minimum of competency. i hope that isn't too much to ask. Don't you see how totally incongruent your position is ? You say that the old systray has been abused, and thus all freedom needs to be taken away from the application writers. And then you turn around and ask for total blanket freedom to be given to the 'visualization' writers, because 'they aren't idiots'. To give some concrete examples of the kind of missing guidance that is needed to make this API useful for application writers: org.freedesktop.StatusNotifierItem.Title STRING org.freedesktop.StatusNotifierItem.Title (); It's a name that describes the application, it can be more descriptive than Id. Is this supposed to be a single word, a line, a paragraph ? Is it supposed to include punctuation, or be capitalized ? Should it be the same as the name that appears in the menu ? Not specifying these things sure makes the spec flexible, but it also guarantees that you will get a mix-and-match of different styles, which will suck for the overall experience. Unless, as Dan pointed out, you rely on everybody copying the one reference implementation in its behavior - and then why bother with a spec in the first place ? ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
