StatusNotifierItem specification status and proposal

[Sergio Costas]

Hello,

I've been checking the current specs, and I see that the 
StatusNotifierItem specification is still in "draft", and that it 
doesn't seem to be in the freedesktop's gitlab, so I presume that any 
suggestion must be done here, in the list.

First, I wonder what happens with the "Ayatana Indicators" way of 
registering an indicator: just creating an 
/org/ayatana/NotificationItem/XXXX inside whatever public DBus interface 
the program has, and adding inside an org.kde.StatusNotifierItem 
interface. After checking the KDE implementation, it clearly doesn't 
follow it, but instead only follows the method specified in the public 
specification. Do you think that the "Ayatana" way would be interesting 
for the spec? AFAIK, that would allow to show Tray Icons from flatpak 
containerized applications without needing to add specific permissions 
(currently, it seems that you must add an option to allow it to work).

Also, I was wondering if adding support for sending SVG icons directly 
"over the wire" would be interesting. I mean: currently it is possible 
to send either an icon name, or a binary representation of an icon. The 
later gives a lot of flexibility to the application, because it can, if 
desired, generate icons "on-the-fly", but has the problem that, being an 
ARGB binary representation, they must have an specific size. Also, due 
to this limitation, there seems to be some implementations that don't 
support this method (as stated in the KDE code), so if an application 
uses that, it is possible that just a blank rectangle will be painted.

So, my idea was to add a new set of methods 
(org.freedesktop.StatusNotifierItem.IconSVG, 
org.freedesktop.StatusNotifierItem.OverlayIconSVG, 
org.freedesktop.StatusNotifierItem.AttentionIconSVG), that allow to send 
a SVG icon (this is, a string with the XML that forms the SVG) from the 
application to the tray, and add it in a new version of the API, thus 
ensuring that the application can know if the tray has that capability 
or not, and be able to fallback if needed. This would give all the 
flexibility of custom icons, and all the flexibility of scalability, 
among with being able to create theme-aware symbolic icons.

Opinions...?