On 22/03/2010 04:41, Ted Gould wrote:
> On Fri, 2010-03-19 at 14:28 +0000, Aurélien Gâteau wrote:
>> The problem is Amarok uses a generated image for its indicator icon (it
>> shows the playback progress). I suspect indicator-applet does not
>> support passing an image by pixels rather by name.
>
> Yes, so isn't this a bug in Amarok not providing an image name as a
> fallback for clients who don't use bitmap based icons?
There is no notion of image name being a fallback to the bitmap version
in the StatusNotifierItem protocol. This should probably be clearly
defined (the spec has a FIXME which propose the opposite behavior).
Anyway, KDE implementation does not let the developer specify both
versions right now: if you set the icon by pixmap, it unsets the name
and vice-versa.
I just sent a hackish patch to Jonathan Riddell which prevents Amarok
from using pixmap based icons (or overlays) when running on GNOME. This
should work-around this bug.
On 22/03/2010 04:41, Ted Gould wrote:
> On Fri, 2010-03-19 at 14:28 +0000, Aurélien Gâteau wrote:
>> The problem is Amarok uses a generated image for its indicator icon (it
>> shows the playback progress). I suspect indicator-applet does not
>> support passing an image by pixels rather by name.
>
> Yes, so isn't this a bug in Amarok not providing an image name as a
> fallback for clients who don't use bitmap based icons?
There is no notion of image name being a fallback to the bitmap version
in the StatusNotifierItem protocol. This should probably be clearly
defined (the spec has a FIXME which propose the opposite behavior).
Anyway, KDE implementation does not let the developer specify both
versions right now: if you set the icon by pixmap, it unsets the name
and vice-versa.
I just sent a hackish patch to Jonathan Riddell which prevents Amarok
from using pixmap based icons (or overlays) when running on GNOME. This
should work-around this bug.