I've seen it happen a few times, but definitely not always.  May be related to
6729?

Looks like it (maybe even a dupe):

Nokia-N900-42-11:~# apt-get install midori
[...]
Setting up midori (0.2.1-0git1) ...
gtk-update-icon-cache: Failed to open file
/usr/share/icons/hicolor/.icon-theme.cache : File exists

and sure enough the default icon is displayed in app launcher.

Re-testing welcome after the "fix" to bug 6729 has been released.

Comment 3 Andre Klapper 2009-12-16 05:03:17 UTC

*** Bug 7012 has been marked as a duplicate of this bug. ***

I'd like to cinfirm this bug. This always happens to me, everytime i install
something new!

Comment 5 Andrew Flegg 2009-12-23 01:27:15 UTC

*** Bug 7241 has been marked as a duplicate of this bug. ***

Comment 6 Andrew Flegg 2009-12-23 01:34:32 UTC

*** Bug 7245 has been marked as a duplicate of this bug. ***

Comment 7 Andrew Flegg 2009-12-23 01:34:57 UTC

(In reply to comment #5)
> *** Bug 7241 has been marked as a duplicate of this bug. ***

This is incorrect. Sorry for the noise.

Comment 8 Andre Klapper 2009-12-31 18:04:00 UTC

(In reply to comment #2)
> Re-testing welcome after the "fix" to bug 6729 has been released.

Anybody with access to PR1.1 community builds having time to retest this?

Comment 9 Andre Klapper 2010-01-05 23:34:30 UTC

This should be fixed in PR1.1 anyway by dropping gtk-update-icon-cache (see bug
6729 comment 5).

If anybody runs into this using the next feature update, please reopen.

I got this issue with 2.2009-50-1 which is PR 1.1 I think.

Comment 11 Andre Klapper 2010-01-06 15:16:11 UTC

(In reply to comment #10)
> I got this issue with 2.2009-50-1 which is PR 1.1 I think.

With which application so I could retry? Also current PR1.1 is 2.2009.51-1

IIRC I got this bug with at least the "London tube map" application and
Emerillon.

Just reproduced on 2.2009.51-1 with gweled, installed via application manager. 
After a reboot the correct icon is shown in the launcher.

Comment 14 Andrew Flegg 2010-01-07 12:54:58 UTC

Reproduced on 2.2009.51-10:

* Installed iNES, Speccy and VGBA from Extras-testing one after another via
Application Manager
* Went to "More..." menu, all THREE have blue square icons.

Happens with 1.2009.44-1 too. Installed iNES, VGB, Mancala, Crimson Fields and
Jamaendo, all of them are missing proper icons. After restarting hildon-desktop
icons are shown.

Comment 16 Andre Klapper 2010-01-11 16:52:34 UTC

(In reply to comment #15)
> Happens with 1.2009.44-1 too.

That's normal if it still happens in a later version (2.2009.51)... ;-)

Comment 17 Andre Klapper 2010-01-14 12:33:09 UTC

Today Nokia released the Maemo5 update version 2.2009.51-1 for public (also
called "PR1.1" sometimes).
If you have some time we kindly ask you to test again if the problem reported
here still happens in this new version - just leave a comment (and feel free to
update the "Version" field to the new version if it's still a problem).

Just tested - the bug is still present in PR1.1, version field has already been
changed to 2.2009.51-1.

I can confirm. PR1.1, installed 4 apps, all have the default icon until reboot.
Left it there for hours (older firmware sometimes fixed itself after a while).

I don't know how important this is, but updating the software seems to work, as
opposed to new installs. Numpty Physics got and update that put an icon in the
menu (used to be CLI only), and it appeared right after the update was
installed.

I am only 99% sure, I wasn't watching this at the time.

I observe the same with Maep app and with my Theremin app.

After rebooting the device, icons appear.

Version: 2.2009.51-1

gtk-update-icon-cache does not work.
OS 2.2009.51-1

With SDK :
[sbox-FREMANTLE_X86: ~] > gtk-update-icon-cache -f /usr/share/icons/hicolor
gtk-update-icon-cache: Cache file created successfully.
[sbox-FREMANTLE_X86: ~] >

On the device :
Nokia-N900-42-11:~# gtk-update-icon-cache -f /usr/share/icons/hicolor           
Nokia-N900-42-11:~#

No result.

I didn't update my SDK since the last fremantle update

Comment 22 Andre Klapper 2010-01-27 13:18:06 UTC

(In reply to comment #21)
> gtk-update-icon-cache does not work

That's why this bug is in "NEW" state and not FIXED. :)

Icon caches have been disabled to work around bug 5450 (see also bug 6729).

Comment 24 Andre Klapper 2010-02-16 15:43:16 UTC

A partial fix went into today's 3.2010.02-8 release (called "PR1.1.1"
internally). The complete issue will be fixed in the upcoming PR1.2 release.

(In reply to comment #24)
> A partial fix went into today's 3.2010.02-8 release (called "PR1.1.1"
> internally). The complete issue will be fixed in the upcoming PR1.2 release.
> 

Can you elaborate on "partial"?

Comment 26 Andre Klapper 2010-02-16 15:54:44 UTC

Reading the internal ticket again it seems that it was too late yesterday
evening when I wrote down comment 24 for my todo list for today.
Sorry for the noise, ignore it. :-(

Comment 27 Andre Klapper 2010-02-17 21:15:20 UTC

This has been fixed in package
gtk+2.0 2:2.14.7-1maemo28+0m5
which is part of the internal build version
10.2010.06-14
(Note: 2009/2010 is the year, and the number after is the week.)

Checked with Qik 0.0.50.

A future public update released with the year/week later than this internal
build version will include the fix. (This is not always already the next public
update.)
Please verify that this new version fixes the bug by marking this bug report as
VERIFIED after the public update has been released and if you have some time.


To answer popular followup questions:
 * Nokia does not announce release dates of public updates in advance.
 * There is currently no access to these internal, non-public build versions.
   A Brainstorm proposal to change this exists at
http://maemo.org/community/brainstorm/view/undelayed_bugfix_releases_for_nokia_open_source_packages-002/

Comment 28 Andre Klapper 2010-03-15 20:54:13 UTC

Setting explicit PR1.2 milestone (so it's clearer in which public release the
fix will be available to users).

Sorry for the bugmail noise (you can filter on this message).

The problem still persists in PR1.2. User still has to reboot the device to be
able to see the application icon.

Comment 30 Andre Klapper 2010-05-27 14:16:08 UTC

(In reply to comment #29)
> The problem still persists in PR1.2. User still has to reboot the device to be
> able to see the application icon. 

Exact steps to reproduce please, otherwise this is not helpful.

The exact steps are already available at the first message of the list and it
*is* helpfull.

In other words, just install any application from application manager. 99% it
won't have in icon until hildon-home (or hildon-desktop - don't remeber) is
restarted.

To see it yourself just install wifieye. Look at the blue icon, then restart
the device.

Comment 32 Andre Klapper 2010-06-01 13:46:28 UTC

(In reply to comment #31)
> The exact steps are already available at the first message of the list and it
> *is* helpfull.

Nope as "More" does not exist anymore. But after re-reading this I assume that
it's about

The scope of bugs.maemo.org are bugs and only very specific and no-brainer
enhancement requests. This report contains a feature request that is too
generic for bugs.maemo.org. Please post this problem and propose your
solution in Maemo Brainstorm instead:
  http://maemo.org/community/brainstorm/

More information: http://wiki.maemo.org/Maemo_brainstorm

Comment 33 Andre Klapper 2010-06-01 13:46:45 UTC

Argh. Sorry. Misclicked.

Comment 34 Andre Klapper 2010-06-01 13:47:57 UTC

(In reply to comment #31)
> In other words, just install any application

I cannot reproduce this with "any" application. Hence asking for exact steps.

After installing an application, the icon of the last installed application is
the "blue box" (default icon)) instead of the actual icon. For example, if you
install wifieye you will see a "wifieye" entry in programs but it will not have
the correct icon. After restarting the device the correct icon appears.

IIRC, when the first post was sent, applications were not sorted by name
(PR0?). Thus, it was "the last icon" / "last entry".

Comment 36 Andre Klapper 2010-06-01 23:45:36 UTC

(In reply to comment #35)
> For example, if you install wifieye

Thanks. That was the testcase I asked for (specific steps to reproduce bugs).
:)

So I installed wifieye, clicked away the success banner, closed App Manager,
clicked in the upper left corner to get the App Menu, scrolled down and the
icon is there.

I've tried this on my two N900s, both with 10.2010.19-1 installed via
on-the-air software update, and on both I cannot reproduce the problem.
The icon is directly shown.

For me this bug is easily visible in the SDK i386 as well. I build a .deb
package for a qt application (strictly following the Wiki "Package a Qt
application" with some changes suggested from mobileqt.de). Both on the SDK
i386 and on my N900 the icon is shown in the menu - the blue box is shown only.
The icon is correctly copied to
/usr/share/icons/hicolor/scalable/hildon/<my-application>.png.

When I restart the SDK (af-sb-init.sh stop followed by af-sb-init.sh start) the
icon shows up. Same is true if I reboot the N900.

But I have to say that the icons are not always missing if I install software
on my N900. Sometimes the icon shows up immediatly. And I don't need to reboot
the N900 - usually the icon of an application shows up after I installed
another application (but the icon for this new application may be missing
then).

Comment 38 Andre Klapper 2010-06-03 16:48:37 UTC

I really wonder what could block the correct updating of the icon.
As I said before it simply works fine for me here. :-(

(In reply to comment #38)
> I really wonder what could block the correct updating of the icon.
> As I said before it simply works fine for me here. :-(

I also don't know and there are at least two applications that work for me too.
I don't remember them but I clearly remember that their icons showed
immediately.

You can always try this on an SDK image.

p.s. I'm using catorise but I don't see how it can affect this (except from
creating a very long delay which could help a race condition)

It works for me on PR1.2.
I installed couple of apps from extras and their icons were there immediately.

Confirming bug is NOT fixed in PR1.2. Though is is really low priority for me.

I just purged wifieye and re-installed it and the icon showed-up immediately.

Since I've not tested this on the device with PR1.2 I can't be sure. However
I'm sure that it happened in SDK after a full upgrade.

Are icons affected by tracker or thumbnailerd in any way? Until a couple of
days ago I had a lot of images (all of Dilbert) which seemed to affect new
image handling.

(In reply to comment #38)
> I really wonder what could block the correct updating of the icon.
> As I said before it simply works fine for me here. :-(
> 

Steps to recreate in PR1.2 :
1. Reboot the phone.
2. Install any app that you don't have at the moment.
or
1. Remove an app you currently have with app-man or apt-get remove
2. Reboot the phone.
3. Reinstall it, Icon will be blue-box until reboot.
or
1. Install deb package with "dpkg -i <name>" - I installed horizontal-call
today
and have had this problem.

I didn't have this issue wity PR1.2 until the other day after installing Zen
Bound off the OVI store. The icon remained a blue square until later the same
day when I re-installed Vagalume which had been removed a few weeks ago.

Seems this one is a right pig to track down.

Confirming for Zen Bound. I had it once or twice with PR 1.2 before but
couldn't remember which packages.

(Happened a lot more often before PR 1.2.)

Comment 46 eileen.khoo 2010-06-23 04:57:49 UTC

Happens to be all the time in PR1.2

FOr new applications that i installed, the icon is a square box.

After restart, the application's icon is showing.

For re-installation, it is ok.

Comment 47 Andre Klapper 2010-06-23 11:56:22 UTC

"Template packages produced with Nokia Qt SDK cause the icon problem.
Adding gtk-update-icon-cache resolved the issue, so the problem was in wrong
package template that Nokia Qt SDK contained and every developer used."
This has been fixed now.

Comment 48 Andrew Flegg 2010-06-23 11:59:50 UTC

Didn't an earlier bug say that gtk-update-icon-cache was no longer required?
Developers have been told that they don't need to use it (as of PR1.1, IIRC)

(In reply to comment #47)
> "Template packages produced with Nokia Qt SDK cause the icon problem.
> Adding gtk-update-icon-cache resolved the issue, so the problem was in wrong
> package template that Nokia Qt SDK contained and every developer used."
> This has been fixed now.
> 

Hi,
Can you elaborate on where gtk-update-icon-cache should be added to overcome
this issue till a new sdk is released with the new template?

(In reply to comment #47)
> "Template packages produced with Nokia Qt SDK cause the icon problem.
> Adding gtk-update-icon-cache resolved the issue, so the problem was in wrong
> package template that Nokia Qt SDK contained and every developer used."

I'm fairly certain that /that/ was not what resolved the issue. 
/usr/bin/gtk-update-icon-cache has been a nop script since PR1.0.1 and still is
in
<http://repository.maemo.org/pool/fremantle/free/g/gtk+2.0/libgtk2.0-bin_2.14.7-1maemo31+0m5_armel.deb>.

I would guess that this bug is a race condition. I believe that the same
procedure and/or software performs different from time-to-time. For example,
when packaging a program of mine I tried to clone another program. The reason
was that the icon was shown with that program... but I failed.

Can it be because of the icon/.desktop file order or the delay between their
installation?

Also, I reopen the bug as it is not fixed. gtk-update-icon-cache is a noop
since the first update. It is just the following shell script:

#!/bin/sh -e

(yes, that one line)

SPiN, installef from the Ovi Store today, shows with the blue standard icon.

Assigning to me

Created an attachment (id=3015) [details]
Patch for GTK

Ok, there are two things here:

1) First is that when GTK tries to detect whether the icon theme has changed,
   it will only check the base directory (e.g. /usr/share/icons/hicolor), but
   NOT its subdirectories, where the actual icons are installed
   (e.g. 64x64/hildon). Calling gtk-update-icon-cache used to be enough, since
   it modified the base directory, but it's useless now that it's a no-op.
   The attached patch makes GTK check all subdirectories too.

2) Second, although gtk-update-icon-cache was disabled because we're not using
   the icon cache anymore, I think we could make it update the timestamp of
   the theme directory, so we have a way to make GTK read all icons
   again. Something like this:

     #!/bin/sh -e

     [ -d "$1" ] && touch "$1"

   But note that something like this alone won't fix the problem, especially
   when many packages are not calling gtk-update-icon-cache.

Confirming that this is still an issue in PR1.3. No UI changes since PR1.2, so
the steps to reproduce the bug stay the same (e.g. comment 43).

Comment 56 Andrew Flegg 2011-04-13 12:45:10 UTC

Bug 12144 describes how to fix this in the CSSU. It might be worth making it a
dupe and moving this to CSSU.