Proposing the StatusNotifier specification

[Giles Atkinson]

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)."

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.

Thanks,

Giles

-----Original Message-----
From: xdg-bounces at lists.freedesktop.org [mailto:xdg-bounces at lists.freedesktop.org] On Behalf Of Aaron J. Seigo
Sent: 19 January 2010 18:44
To: xdg at lists.freedesktop.org
Subject: Re: Proposing the StatusNotifier specification

On January 19, 2010, Giles Atkinson wrote:
> > Do you have concrete examples? every app we looked at that puts an icon
> > in the tray (and there are dozens) fits into one of the existing
> > categories; in fact, that's how we came up with them.
> 
> Yes, I do and it is not an isolated case, but an example of a reasonable
> class of applications: those that present foreign windows from another
> environment and wish to integrate them as smoothly as possible with the
> local environment.  This class potentially includes remote graphics
> applications, VM hypervisors and emulators such as WINE.  (At the edge of
> it are straightforward applications using X remote display, whose use of
> the replacement notification interface is blocked by the sole use of
> D-bus.)

if this information is not known, then i'd suggest tagging them as 
ApplicationStatus since that's the best that can be done.

as an implementation note, the Plasma widget that provides the system tray for 
plasma-desktop and plasma-netbook treats all xembed icons as 
"ApplicationStatus" since we can't introspect any additional information out 
of them.

so in the case of "no information available", we default to 
"ApplicationStatus"

> Applications in this class only have the information about their
> notification items that they get through the underlying foreign
> interfaces, and that is very unlikely to include anything that
> approximates the four categories. 

is there information in these systems that offers a categorization? if so, 
then we can work on harmonizing our categorizations with common practice 
elsewhere. if there is no category information, then i suggest using 
ApplicationStatus as a default fallback.

> That could be interpreted as meaning
> they are barred from this interface, 

that would be an incorrect interpretation. would it help if the entry for 
ApplicationStatus was extended from:

"ApplicationStatus: The item describes the status of a generic application, 
for instance the current state of a media player."

to something like:

"ApplicationStatus: The item describes the status of a generic application, 
for instance the current state of a media player. In the case where the 
category of the item can not be known, such as when the item is being proxied 
from another incompatible or emulated system, ApplicationStatus can be used a 
sensible default fallback."

?

> but in practice the application developers will simply make them lie.  

if you can describe some use cases in which the developer will make the item 
lie (e.g. "this is supposed to be a $FOO system tray entry on Windows, and 
when run through $COMPATIBILITY_LAYER it will likely end up appearing as $BAR 
instead") then we can work on this.

> On the subject of backward-compatibility you also wrote:
> 
> ... older clients aren't ignored at all (at least if the host
> visualization (e.g. system tray), doesn't suck). the goal is to deprecate,
> and eventually get rid of, the old and broken xembed based system
> 
> That is all very well, and what anyone might want to hear, but it is not
> what is in the specification. 

the specification does not require all visualizations to also support the 
xembed system. that is because not all visualizations will be system trays and 
the spec is not about the xembed system but a different system that provides 
far greater capability than the xembed system which sits aside the xembed 
system.

i really do hope that we can phase out the xembed system in our own 
applications. whether we can do so for things like apps running through WINE 
is not a given; i think it's obvious that apps using the xembed system will be 
with us for many years to come. as such, it's only reasonable to expect that 
people who write system trays will include xembed support as well. it is not, 
however, in the scope of this specification to mandate how system tray wigets 
are written. the scope is to define how a visualization, which a system tray 
is one possible kind of, can work with applications using this d-bus based 
mechanism.

> As I have already mentioned, the
> specification is completely silent on compatibility with older clients,
> implying it is not an issue.  The addition of a single sentence would fix
> that.

if you could offer an example of the sentence you have in mind, that would be 
helpful.

> It is also silent on the motivation for the design (which still looks weak
> to me) and the semantics of the operations parameters, as Matthias has
> pointed out in another thread.

the semantics of the operations as realized in a given visualization are not 
overly specified to purposefully allow for flexibility in the visualization. 
yes, there is an assumption here that those writing those visualizations 
aren't idiots and are able to do their job with a bare minimum of competency. 
i hope that isn't too much to ask.

as for the motivation of the design, i agree that it is not obvious (as 
evidenced by these discussions). we will add a bit about the motivation for 
the design somewhere, perhaps as an apendix?, to the spec. i'm not a fan of 
such text as part of formal documentation, but if it helps it helps and it 
should go 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
xdg at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg