Icons of some notifications are not shown properly

Thank you for the bug report. I think the problem may be the order we choose the icons, only trying the image attached to the notification last. I will switch the order around and do a rebuild for lucid this afternoon.

I have uploaded 0.4.47-1~ppa~lucid which reorders the icon priority a bit, to match the Desktop Notifications Specification. If you could test the package and let me know if it fixes your issue, that would be great.

There is still a chance that it may still not work. We now check first for the image_data hint, where I hope your icons are, then try the image-path hint followed by the app_icon member.

Lastly, we check the old icon_data hint, so it may still be broken if your app uses that, but also sets app_icon or image-path. If that is the case, and it still doesn't work, please enable debugging in the preferences and check ~/.cache/recent-notifications.log to see what your app is using.

I can fix it to check both image_data and icon_data first, it really shouldn't hurt anything, but I would prefer to use the priorities from the spec so that it matches the way in works in the newer gnome3 version of recent-notifications.

Unfortunately, it's still the same.
Typical debug message on chromify-osd notification goes like this:

2012-03-25 13:43:11,142 Notification DEBUG:
--------------------------------------------------
Message created at: Sun 25 Mar 2012 01:43:11 PM
app_name: 'chromify-osd'
replaces_id: dbus.UInt32(0L)
app_icon: '/tmp/chromifyosd_image'
summary: 'New mail from Facebook: Yaroslav Ashikhmin (friends with Alina Korbut) also commented on Alina Korbut...'
body: 'facebook Hi Allis, Yaroslav Ashikhmin (friends with Alina Korbut) also commented on Alina'
actions: dbus.Array([], signature=dbus.Signature('s'))
expire_timeout: dbus.Int32(-1)
hints:
--------------------------------------------------
The file /tmp/chromifyosd_image contains icon of the last, not the first notification — that I've checked.

Additionally here's a java console log line from Chrome which shows standard message from chromify-osd:
"Dispatched! Someone liked your post ... http://cs305201.userapi.com/u26291096/e_e2714c5d.jpg"
And this is the corresponding java-script code:
——————————————————————————————————
var chromifyOSDComEvent = document.createEvent("Event");
chromifyOSDComEvent.initEvent("chromifyOSDComEvent", true, true);

var container = document.createElement("div");
var c1 = document.createElement("div");
c1.innerHTML = title;
var c2 = document.createElement("div");
c2.innerHTML = body;
var c3 = document.createElement("div");
c3.innerHTML = iconUrl;
var c4 = document.createElement("div");
c4.innerHTML = "text";
container.appendChild(c1);
container.appendChild(c2);
container.appendChild(c3);
container.appendChild(c4);
container.id = "chromifyOSDComObject";
container.style.display = "none !important";
document.body.appendChild(container);

document.dispatchEvent(chromifyOSDComEvent);
console.log("Dispatched!", title, body, iconUrl);
——————————————————————————————————

Maybe I should file the bugreport to chromify-osd instead?

Oh, I think I see the problem now, that is a weird way to do it. Just to be clear, /tmp/chromifyosd_image will be a diiferent image each time ( or at least sometimes), correct?

If that is the case, do you only see the first icon correctly? Recent notifications caches the icons, so once /tmp/chromifyosd_image is loaded, it will always be the same until you clear the messages, which should clear the cache as well.

I can add an option to disable icon caching. If you would like to test to see if it works first and you have bzr installed,

bzr branch lp:recent-notifications

Then in that directory, comment out recent_notifications/Icon.py lines 33 and 47 (put a # in front). They look like:

      icon_cache[(name, size)] = icon

Then you can run the applet in a window to test with

./recent-notifications -w

Or scripts/build-package.sh -b will build a deb if you have the correct tools installed. It ends up in dist/deb.

I will see about adding an option to disable the caching soon, let me know if you decide to test it and it doesn't work, thanks!

Oh you may need to uninstall the version you have temporarily before running from the bzr branch, otherwise it may use the old code instead.

Or, better than an option, maybe we could check to see if the file was modifed and then load a new image in that case.

Yes that's correct and a weird way to provide an icon it is indeed.
Yet I see only two other possibilities: either chromify-osd should generate a different icon filename (then it should work correctly with caching mechanism which isn't the one I think needs to be disabled); or notification daemons and recent-notifications should use any urls (local or remote) transparently which is not the case now I suppose and never will be.
I'm not an expert though. Maybe you could think of another more correct alternative?

I pushed up a new revision to lp:recent-notifications which I think may fix it if you could test it out. Just run it locally as in the previous comment, no need to uninstall anything. Just want to make sure it is actually working before pushing out a new version. (It works with my tests, but I don't have chromify-osd so I may be missing something).

I added a bit of code to check the modified time of the file, and load a new icon if it changed. I think this is probably the correct way to handle it at our end. It is entirely possible an icon may be updated, so we shouldn't assume the cached version is always fresh.

As for chromify-osd, the way this is normally handled, where icons change frequently (such as with pidgin and gwibber), is to embed the image into the notification using the image_data hint (see the Formats section of http://developer.gnome.org/notification-spec/#icons-and-images ). But it may not be possible for chromify-osd to do that, I don't know, so hopefully the latest changes should fix it on recent-notifications side.

Thanks a lot, that did the trick!

Nevertheless I'll try to contact chromify-osd developer and ask if he would find the proposed method with the image_data hint acceptable and preferable.

Excellent! I have uploaded the fixed package to the ppa (for lucid).

recent-notifications (0.4.49-1~ppa~lucid) lucid; urgency=low

  * New upstream release.
    - Check modified time on icons to see if the cache is stale (LP: #963805)

 -- Jason Conti <email address hidden> Sun, 25 Mar 2012 13:34:18 -0400