Proposing the StatusNotifier specification

[Giles Atkinson]

Marco,

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.

Giles

-----Original Message-----
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:
> 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
_______________________________________________
xdg mailing list
xdg at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg