Proposing the StatusNotifier specification

[Marco Martin]

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?


> It might also be useful to specify the mapping between the interfaces,
> insofar as one exists.  For example WM_NAME, might map to "Title" in the
> new interface.
> 
yes, as Aaron said, this would be useful and help on that would be really 
appreciated :)

Cheers,
Marco Martin