On January 20, 2010, Michael Pyne wrote: > On Wednesday 20 January 2010 12:10:44 Marco Martin wrote: > > > Having the visualization be in control of presentation is great, but > > > you need to give the app authors *something*. 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. And so the > > > StatusNotifierIcon would have to be entirely redundant with > > > functionality that was also provided elsewhere. > > > > (open question) we could have some -recomended- scenarios for > > different kind of implementations? like desktop use case, mobile use > > case, text only... > > i fear it would kill great part of the flexibility however > > Well there's no reason we can't provide examples for how the various > components (e.g. the title, icon) would be used in practice.
which would be ultimately unreliable given that visualizations may behave differently. the common mistake here is to consider this spec as a design guide for system tray widgets. it's not. it is a description of how to get data from applications regarding their status to other applications which would like to integrate that data. a primary user of the data (at least right now) will be "traditional" system trays. this is a shift towards a more service oriented environment and away from an overly prescribed system that welds the applications and the device environment so closely that we end up seeing people reimplement the entire thing everytime they want to do something even a little differently. as examples of that, i give you Canonical's application indicators and Maemo's systray-like icons. i think it's fine to define what the data published should look like so that both the entries and the visualizations of them can operate with greater confidence. but defining the visualization interaction patterns isn't going to fly. application developers (and i'm one of them) simply have to get used to the idea of operating in environments that provide access to services and which craft the user experience appropriately for the context. this is the business of the primary user interface (desktop shell, netbook shell, etc) and not the applications. why? because applications will do it differently from each other (consistency issues) and only the primary user interface knows what is contextually appropriate (e.g. are we using a Dock or a taskbar+system tray; is it a desktop or a smartphone; etc...) > for things like what > signal do I need to use if I want to intercept the mouse wheel of the > systray? org.freedesktop.StatusNotifierItem.Scroll we have tried to cover the needs of application development. really we have. because we are also application developers. (and you shouldn't consider it in terms of "mouse wheel" but in terms of "my status entry has been asked to scroll, for whatever that means in the context of my status entry and application"; as you can see, the service concept is actually pretty symmetrical in that regard since visualizations don't get to interpret what scrolling results in :) -- 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
