On May 19, 2010, Wolfgang Draxinger wrote: > For general purpose messaging a system like "StatusNotifierIcon" is the > most appropriate solution, however I'd call it "StatusNotifier" (not > -Icon).
We call them "StatusNotifierItems" in the spec. (Yes, the original subject line is incorrect, as there is no "StatusNotifierIcon". :) > The other are mini applets which are highly application specific. And > those you will never be able to map all of them into a unified > look-and-feel status notifier system, because there always might appear > a program which requires some elements, which can't be implemented in a > elegant way through a limited set of markup-widgets. Then the app is doing something it shouldn't be. System tray abuse may appease the application deveoper, but it does very little for the user. We have successfully transitioned all the apps in our repository over to the new protocol without problems. Some apps have required minor adjustments, but the result tends to be an improvement in user experience. So in practice it works well. For apps that do things like "show a network usage graph in the system tray", they need to die a quick and painless death. That is was native widgets/applets are for, and they do a much, much better job of it. In the Plasma workspaces, more and more of the hardware oriented entries are actually applets due to the increased expresiveness and flexibility they provide. The user only sees a bunch of icons in the system tray, of course. They don't care how they get there. Only that they are harmonious and work as well as they can. It's therefore up to us, the designers of these environments, to make reasonable decisions that will deliver those results. Application developers need to move away from the idea that the system tray is a ghetto for their unique perspective on life to express itself in. It's a very specific kind of tool that fits into the user experience in (hopefully) some very well defined ways. We are purposefully working _away_ from "no holds barred" usage of the system tray by applications and towards a system with well defined constraints and allowances. This may well be a difference in philosophy with some other viewpoints. It is, however, the one some of us are taking and we really have no desire to go backwards on it. It's paying off too many dividends for us to do so. :) -- 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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
