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 [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
