AurélienRE: Proposing the StatusNotifier specification

[Marco Martin]

On Wednesday 06 January 2010, Giles Atkinson wrote:
> Aurélien,
> 
> 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
>  comments.
> 
> 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 
another desktop)
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 
there once.

Cheers,
Marco Martin