Proposing the StatusNotifier specification
Giles.Atkinson at eu.citrix.com
Wed Jan 6 11:28:54 PST 2010
Thank you for your comments on those of mine. I agree that most of your remarks on item 1 make sense, but can not agree with "... Xembed seems pretty slow ...", as in this case it comes down to little more than reparenting a window. And I was not clear what windows you are talking about here: "... and forcing argb visuals on those windows seems to cause several problems both in terms of graphic corruption or stability of the apps".
For item 2, my concern is that there is no generic, or catch-all category, so that potential clients that do not fit in one of the four listed categories are excluded. I assume that one purpose of the categories is to allow users some control of which clients are actually displayed. Such filtering should be under user control, not inherent in the specification of the notification mechanism.
On item 3, you wrote: "... well, exactly how to do that is kinda outside the scope of the notification, (besides recommending to use the old way as fallback)". My concern here is that the specification does not recommend using the old way, except when an active implementation of the new specification is not present. (At least, that is my reading of it.) That means that any older clients are ignored.
From: xdg-bounces at lists.freedesktop.org [mailto:xdg-bounces at lists.freedesktop.org] On Behalf Of Marco Martin
Sent: 06 January 2010 19:03
To: xdg at lists.freedesktop.org
Subject: Re: AurélienRE: Proposing the StatusNotifier specification
On Wednesday 06 January 2010, Giles Atkinson wrote:
> Your message below prompted me to read the specification, something that
> has been on my "to do" list since the original post. I do have a few
> 1) This represents a huge increase in complexity and in dependencies for
> client programs. (The client side of the previous specification can be
> implemented in a handful of Xlib calls.) It would be useful to indicate
> what problems will be solved by the change.
there are several, like
it's not possible to have more than one instance of the same icon if it
doesn't seem a big deal at first it could be an issue for a multi monitor
setup for instance.
there is absolutely no communication between the tray host and the app, so the
tray doesn't know if an icon has been idle for hours, so quite unimportant or
if is for instance an im ap icon that is blinking screaming for attention, so
is not possible to display the notifying ones in a more prominent way or
hiding the one that asks so (hiding of icons can only be manual right now)
the host doesn't have any control on painting of the icon, so can't try to use
an icon from the current desktop them for instance (even if the app comes from
or do kinds of transformations like tinting, rotating or even scaling the icon
to other sizes (while the embedded window should be scalable in theory, in
practice seems to be hardcoded to 24x24 pixels most of the cases)
is not possible to have other means other than visual to use this, like simple
logging or text to speech
and others more due to bugs maybe that could be overcomed in the future but
enough experience degrading to justify to ask ourselves if this was the
correct way afer all, Xembed seems pretty slow and forcing argb visuals on
those windowsseems to cause several problems both in terms of graphic
corruption or stability of the apps
> 2) The set of four permitted notification categories seems very
> restrictive. Is that deliberate?
yes, i would be not really possible to have an exaustive list of categories
where applications would fall into and would still have to be an "opinion"
matter, having only few categories is done mostly do distinguish between icons
that should be considered kinda system wide (like hardware and system
services) and ones considered more belonging to a regular user application,
that could even be moved out of the system tray (or moved in a separate one)
some day for instance
> 3) Although there is a section titled "Backwards Compatability", there is
> no compatabilty support for client programs using the old specification.
> Instead it seems that programs are required to implement both, as well as
> make additional D-bus queries.
well, exactly how to do that is kinda outside the scope of the notification,
(besides recomending to use the old way as fallback)
of course this protocol should be implemented by a rather rich client library
(KNotificationItem and libappindicator in this case) rather from scratch by
every single application, so the fallback mechanism should be implemented
xdg mailing list
xdg at lists.freedesktop.org
More information about the xdg