comments on StatusNotifier spec
(So rereading this, it comes across as kinda harsh, but it wasn't supposed to be, so just add a :-) to the end of every line or something. :-) This specification does not define what the aspect of the Noticication Items will be, this is strictly implementation specific. What does aspect mean? (Also, typo: Noticication. Also, Freedestop on the previous line. Actually, the whole spec needs to be seriously proofread, and by a native English speaker.) StatusNotifierHost When I first saw this term in the spec I thought it was talking about having a status icon on one machine and a tray on a different machine. Maybe this is just because I write lots of networking code, but host to me mostly means a computer on a network. Each application can register an arbitrary number of Status Notifier Items by registering on the session bus the service org.freedesktop.StatusNotifierItem-PID-ID, where PID is the process id of the application and ID is an arbitrary numeric unique identifier between different instances registered by the same application. This makes it awkward for two unrelated parts of a single process (eg, plugins) to each put up their own status icon, since they have to somehow coordinate unique IDs between themselves. And I can't see any reason why the spec needs to require that the notifier items have specific D-Bus names anyway. This should just go away; let people call their notifier items whatever they want. org.freedesktop.StatusNotifierItem.Id org.freedesktop.StatusNotifierItem.Title I assume Title is supposed to be localized and Id is not, which you should indicate. org.freedesktop.StatusNotifierItem.WindowId It's the windowing-system dependent identifier for a window No, it's an X Window ID. A windowing-system dependent identifier for a window can't be expressed as a UINT32 on all windowing systems. 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. Making it worse than useless. org.freedesktop.StatusNotifierItem.OverlayIconName This can be used by the visualization to indicate extra state information, for instance as an overlay for the main icon. for instance? So that's just one example of how OverlayIconName might be used? Either it is guaranteed to be overlaid over the main icon, or else it isn't. If it isn't, then no one will use this property, and they'll just change the main icon instead. Also, is OverlayIconName (as opposed to OverlayIconPixmap) actually useful? It seems like you'd need to also specify *where* on the main icon to overlay it. org.freedesktop.StatusNotifierItem.AttentionIconName this can be used by the visualization to indicate that the item is in RequestingAttention state. Again, can? Either it *is* used when the icon is in RequestingAttention state, or else the property is useless and people will just change the main icon instead. org.freedesktop.StatusNotifierItem.AttentionMovieName Movie is not standard terminology. Why not AttentionAnimationName? Movie suggests that it should point to an MPEG or something. An item can also specify an animation associated to the RequestingAttention state. This should be either a Freedesktop- compliant icon name or a full path. The visualization can chose between the movie or AttentionIconPixmap (or using neither of those) at its discretion. Last I knew the freedesktop icon spec did not allow for animated images at all. Also, why does this property allow either a name or a path, but all of the other ones only allow a path? org.freedesktop.StatusNotifierItem.ToolTip Needs to specify whether the icon name overrides the data or vice versa. What should you specify for the name if you're including icon data (and vice versa) since the signature requires both to be present? ContextMenu the x and y parameters are in screen coordinates and is to be considered an hint to the item about where to show the context menu. a hint? You need more than that. In particular, if the status icon is displayed on the top of the screen, then you probably want the menu to appear underneath it, but if the status icon is on the bottom of the screen, then you want the menu to appear above it. Likewise, normally you probably want the menu to be left-aligned with the left edge of the icon, but if the icon is near the right edge of the screen, and the menu would extend off the edge, then you probably want to right-align the menu with the right edge of the icon. So what you need to know is the x,y,width,height of the icon's visualization (including any padding introduced by the host). Either ContextMenu, Activate, and SecondaryActivate could include all 4 of these as parameters, or else they could be available as properties. Signals (Sigh. We need a standard D-Bus property notification interface.) Anyway, this could
Re: comments on StatusNotifier spec
On January 18, 2010, Dan Winship wrote: StatusNotifierHost When I first saw this term in the spec I thought it was talking about having a status icon on one machine and a tray on a different machine. for all that the status item cares, it could be. Maybe this is just because I write lots of networking code, but host to me mostly means a computer on a network. ok; i'm not sure that this matters at all, however. Each application can register an arbitrary number of Status Notifier Items by registering on the session bus the service org.freedesktop.StatusNotifierItem-PID-ID, where PID is the process id of the application and ID is an arbitrary numeric unique identifier between different instances registered by the same application. This makes it awkward for two unrelated parts of a single process (eg, plugins) to each put up their own status icon, since they have to somehow coordinate unique IDs between themselves. And I can't see any reason why the spec needs to require that the notifier items have specific D-Bus names anyway. This should just go away; let people call their notifier items whatever they want. this way we know we won't get naming collisions at runtime, which simplifies things a lot and increases the robustness. i don't know what would be gained by letting developers name notifier items whatever they want. this is a specification for a system running on a computer, not a celebration of human uniqueness ;) org.freedesktop.StatusNotifierItem.Id org.freedesktop.StatusNotifierItem.Title I assume Title is supposed to be localized and Id is not, which you should indicate. yes, good point; user visible strings in the spec should be marked as such. org.freedesktop.StatusNotifierItem.WindowId It's the windowing-system dependent identifier for a window No, it's an X Window ID. A windowing-system dependent identifier for a window can't be expressed as a UINT32 on all windowing systems. true enough; i suppose it's of interest to those who are creating windows shell replacements using plasma-desktop (to find a concrete use case). if we ignore symbian (where i don't know if such information would be remotely interesting anyways), it seems that all of our (qt's and kde's) targets can be handled with an unsigned long. 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. org.freedesktop.StatusNotifierItem.OverlayIconName This can be used by the visualization to indicate extra state information, for instance as an overlay for the main icon. for instance? So that's just one example of how OverlayIconName might be used? correct. Either it is guaranteed to be overlaid over the main icon, or else it isn't. If it isn't, then no one will use this property, and they'll just change the main icon instead. this assumes a i want to control the visualization mentality, which is broken and harmful. the status item (and it's human creator) should not care what the end visualization will be. Also, is OverlayIconName (as opposed to OverlayIconPixmap) actually useful? yes, it's the name of the icon, not a pixmap. It seems like you'd need to also specify *where* on the main icon to overlay it. that's dependent on the visualization more than the item. i can imagine cases where it would be nice to specify where to overlay it, but i can imagine more cases where this would simply break consistency and assume things about the visualization (e.g. size, position and even visibility of the icon) org.freedesktop.StatusNotifierItem.AttentionIconName this can be used by the visualization to indicate that the item is in RequestingAttention state. Again, can? Either it *is* used when the icon is in RequestingAttention state, or else the property is useless and people will just change the main icon instead. 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? so the application which the item belongs to presents as much useful information about the item itself and the visualization decides how to put it together. this way we can account for multiple real-world use cases as well as future proof ourselves. org.freedesktop.StatusNotifierItem.AttentionMovieName Movie is not standard terminology. Why not AttentionAnimationName? Movie suggests that it
Re: comments on StatusNotifier spec
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
Re: comments on StatusNotifier spec
On January 18, 2010, Aaron J. Seigo wrote: 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 should clarify a bit here: such behaviour would be rather bizarre on the part of the visualization and would really make no sense from a usability perspective. so i don't expect apps to have to deal with my window just got destroyed because i passed it to the status item by id or other such oddities in practice. however, the _reason_ for allowing such oddities to even be plausible is so that the results of interaction with the status item in the visualization is *consistent* between applications. the only way to be sure of that is to put the decisions in the hands of the visualization. when we look at what Canonical is doing with their implementation of a StatusNotifierHost, it's sensible (within the scope/aims of their design) but rather different from what may (and does) happen in other implementations. the only reason this is possible, allowing them to create consistencies within their user experience that they are aiming for, is because the decision making happens in the visualization and no applications need to be tweaked or prodded differently at the source code level. yes, this is a (small) shift in thinking on the part of application code (the separation of data and visualization for the system tray), but the status quo is broken and inferior and it's time we made this small shift in thinking. -- 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
Re: comments on StatusNotifier spec
I must say I am a bit taken aback by your responses here. Dan's mail made me look at the spec for the first time, and I have to say he is entirely right in his criticism. The spec is full of awkward naming (StatusNotifierHost, ServiceRegistered, etc), internally inconsistent (e.g there's a ProtocolVersion property, but the document has no version information that I can find), ignores decades old lessons from X (when you pass on events, _always_ include the timestamp), and it is entirely void of expected behaviors for either side of this protocol. But instead of addressing these criticisms, you seem to be only interested in selling your abstraction layer philosophy. Not a good sign for reaching a consensus. Matthias ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: comments on StatusNotifier spec
On Mon, 2010-01-18 at 18:17 -0800, Aaron J. Seigo wrote: On January 18, 2010, Matthias Clasen wrote: The spec is full of awkward naming (StatusNotifierHost, ServiceRegistered, etc), as noted in my replies, i agree that ServiceRegistered should/could be named better. the quibble on StatusNotifierHost was whether Host implies it is a remote system on the network or not, and i addressed that in my reply as well. No, you didn't. You declared that it didn't matter. , ignores decades old lessons from X (when you pass on events, _always_ include the timestamp), i believe that was covered in another thread, and i don't think there was much in the way of debate there. Right. But the point is valid and hasn't been addressed in the spec. and it is entirely void of expected behaviors for either side of this protocol. that is intentional, for the reasons i've described. if you can provide concrete use cases for which it falls down, then that would be great. It falls down for any use case. How do you expect applications to use a service when the only description of the service is: You can put a string here. The field is named 'Title', which should give you a rough idea what this is about. But we won't tell you if we translate it into morse code or signal it to the user via smoke signs.. It just doesn't work. Your defense against this argument so far has been that the examples are absurd and that there will be some implicit understanding of what to expect - what kind of a 'spec' is that, if all the semantics have to be read between the lines ? if by consensus you mean immediately agreeing with everything someone else says then, yes, it's not a great sign. thankfully, that's not the goal here at all. if by consensus you mean striving to arrive at common ground through open discussion leading to agreement and/or compromise then i think we're doing fine. Well, there was a call for the gnome side to 'sign off' on this spec a few days ago. That's what I meant by reaching consensus. note that i do not expect Dan or you to agree with everything i say, either. i am, however, open to and looking forward to continued discussion about the points we don't have shared ground on until we reach a point that we do. what do you think? I think what you have so far may be a workable basis for an API, but as a specification it is not useful. Spec = API/Protocol + Semantics. ___ xdg mailing list xdg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xdg
Re: comments on StatusNotifier spec
On January 18, 2010, you wrote: On Mon, 2010-01-18 at 18:17 -0800, Aaron J. Seigo wrote: On January 18, 2010, Matthias Clasen wrote: The spec is full of awkward naming (StatusNotifierHost, ServiceRegistered, etc), as noted in my replies, i agree that ServiceRegistered should/could be named better. the quibble on StatusNotifierHost was whether Host implies it is a remote system on the network or not, and i addressed that in my reply as well. No, you didn't. You declared that it didn't matter. that is correct; i agreed with one point (ServiceRegistered) and not with another. to reiterate, the Host could be on another machine in the network for all the notifier item cares and it does host the item. there also hasn't been a compelling reason given for why Host in the name is so troublesome as to cause the spec to be changed in this manner. by contrast, ServiceRegistered not being a good name is a very sensible observation that probably does have enough weight to warrant a change. personally, i'm a little confused as to why the term Host is controversial enough for us to be having this precise conversation. :) if there was no openness whatsoever to change, then i could understand. but there's a reasonable openness to change. , ignores decades old lessons from X (when you pass on events, _always_ include the timestamp), i believe that was covered in another thread, and i don't think there was much in the way of debate there. Right. But the point is valid and hasn't been addressed in the spec. many of the issues raised haven't been addressed in the spec yet. the primary author of the spec (Marco) has been traveling since the start of this thread (not that others have been providing patches either :). right now we're gathering issues and they will get addressed in the spec; i actually spoke with Marco since this thread started about this very issue (getting issues with consensus merged into the spec). moreover, this is not the first round of input that has been offered and made its way into the spec. this may be the first time you or Dan have interacted with it, but this spec does already have a track record of accepting input in a reasonable manner. in fact, the requirement that the pixmap data be in network byte order was one such change. so let's give it time, remain reasonable and try to concentrate on the issues rather than talk about talking about issues. and it is entirely void of expected behaviors for either side of this protocol. that is intentional, for the reasons i've described. if you can provide concrete use cases for which it falls down, then that would be great. It falls down for any use case. that runs counter to the fact that we have a well functioning implementation of it that has been shipping for nearly 6 months and in fairly wide usage. How do you expect applications to use a service when the only description of the service is: You can put a string here. The field is named 'Title', which should give you a rough idea what this is about. But we won't tell you if we translate it into morse code or signal it to the user via smoke signs.. It just doesn't work. that isn't a use case. that's using the generalization you already offered as a proof for the same. can you please provide real world use cases where this doesn't work in practice. because we have quite a few real world use cases that span a rather large set of behaviors that shows, quite demonstrably through the experience of shipping code to users, that runs counter to this. these include sound volume, screen resolution, email and instant messaging notification, on disk file indexing processes, network management, clipboard server and many more. in each of these cases the application has been able to communicate, without regard for the resulting visualization, what information regarding its state that it needs to have delivered in the user interface. on the host side, we now have two fairly different host implementations (though admittedly both are visually oriented) that shows how the flexibility on the visualization side can be used without problems to the applications. these are real world use cases, and augmenting those with counter examples, even of the thought experiment sort (the audio visualization is one such though experiment), can be useful. the kind of hand waving and unrealistic examples we're trying to get by on in this discussion aren't exactly useful. Your defense against this argument so far has been that the examples are absurd the solution to that is very simple: provide real world use cases where this won't work (or isn't working, as the case may be). by providing concrete issues to discuss we can have a concrete discussion. and that there will be some implicit understanding of what to expect honestly, i don't expect it to be implicit; that's why i'm engaging in this conversation, in fact. to
