Proposing the StatusNotifier specification

[Aaron J. Seigo]

On January 25, 2010, Marco Martin wrote:
> On Monday 25 January 2010, Giles Atkinson wrote:
> > Aaaron,
> > 
> > Another deferred follow-up, but on 19th January, you wrote:
> > > would it help if the entry for ApplicationStatus was extended from ...
> > > to something like: ...
> > 
> > I think that would answer the category objection entirely.
> > 
> > > is there information in these systems that offers a categorization?
> > 
> > In my case the application just gets an icon image and a text fragment to
> > be displayed on mouse-over.
> > 
> > > if you could offer an example of the sentence you have in mind, that
> > > would be helpful.
> > 
> > How about "Implementations that previously offered a similar service via
> > the Xembed-based system tray specification SHOULD give consideration to
> > support for older clients, maintaining support for the older interface
> > for a transitional period."
> > 
> > I personally would like it if you went further: "They MAY offer support
> > for the older interface indefinitely, for the benefit of applications
> > that may be unable to use the new interface fully, such as those mediate
> > foreign application environments (Hypervisors, emulators, remote
> > graphics applications)."
> 
> should and may? since probably wine will never be able to implement this
> (not really sure how the windows systray works and how wine gives support
> to it) shouldn't the support to the old standard be required indefinitely
> as mandatory at this point?

i don't think this falls under subject matter for this specification. this 
spec is not defining what a system tray widget/applet/visualization must do, 
it defines how to get app status information from an app to a visualization 
using dbus. 

one kind of visualization is a desktop system tray, but it isn't the only one. 
there are systems that simply don't care about things like WINE; this is 
especially true when we leave the realm of "desktop". i just don't see a many 
smartphone type devices ever caring about it, for instance :)

i think adding some advisory language in there is good: people writing a new 
system tray for a desktop environment won't get misled into thinking that 
there is nothing else out there right now. but anything more than advisory 
language is probably stepping outside the boundaries of the topic of this 
spec. it will likely lead to non-compliance by implementations on this one 
point, and writing a spec that we know won't be complied with is not very 
productive.

-- 
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