Unity 2D doesn't load 24 bit icons

Bug Description

[Test Case]
1. Install any application offering a 24-bit application icon (e.g. kmag)
2. Run the application
-> The application icon should be visible in the launcher instead of the ? icon for the application. The icon should also have correct colors.

[Regression Potential]
24-bit icons in the Launcher looking strange (modified colors or similar).

Original description:

Unity 2D 5.8 Precise

When starting an application whose icon is 24 bits, like pendu when installed from source or kmag as installed from the repositories, the icon shown is the ? icon instead of the real application icon

Hi Aurélien, I'm not sure I understand the situation you are describing, could you post some screenshots showing what works and what does not work (use some arrows/text in them) so it is easier for us to understand what the issue is?

In the Dash sorry.
But I tried to remake this bug, and the .desktop, located in /usr/local/share/applications/ is no longer in the Dash.
But last time, there was an entry for this application, but with the unknown icon (the file containing a "?").
If I launch this application, the unknown icon appears in the Launcher. But if I ask xprop for the icon, I see the window icon (which is located in/usr/local/share/pixmaps/).

To sum up :
-Before :
- An entry in the Dash for the application installed in /usr/local, but without the icon.
- The fallback icon in the Launcher when the application is running, even if xprop proved that GTK was able to load the window icon.
-Now :
- No entry for local applications in the Dash
- The fallback icon in the Launcher when the application is running, even if xprop proved that GTK was able to load the window icon.

Can you tell us which application is that so we can try to reproduce the problem here?

Any application installed in /usr/local I think...
In my case, it's a game whose I'm the developer : https://launchpad.net/pendu-gtk
Compile it, don't use the package, else it will work because the deb will install it in /usr/ and not /usr/local/

After having a look at the code it has nothing to do with the icon being at /usr/local/share/pixmaps/ but the icon being of a special format. I'm editing the title and description to fit the issue

I ommited to precise something, the icon is a symlink.

Hello RIVIERE, or anyone else affected,

Accepted unity-2d into precise-proposed. The package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

This bug was fixed in the package unity-2d - 5.12.0-0ubuntu1

---------------
unity-2d (5.12.0-0ubuntu1) precise-proposed; urgency=low

* New upstream release:
- unity-2d-shell crashed with SIGSEGV in ref() (LP: #968046)
- [hud] First entry always activated with keyboard navigation
(LP: #980899)
- unity-2d-shell crashes on autoscrolling on launcher tile removal
(LP: #988239)
- unity-2d-shell crashes when using with a NX server (LP: #983942)
- Dash - update Dash keyboard shortcuts so the 'CTRL + TAB' switches
between Lenses and 'TAB' by itself moves the focus between categories
(LP: #891648)
- [spread] When multiple windows of an app are open, clicking on one
doesn't bring it to the foreground (LP: #917334)
- [HUD][multi-monitor] HUD should be expanded to the left if used on a
screen without launcher (LP: #979927)
- unity-2d scope un-url-escapes values from its model (LP: #986175)
- [places] tab key does nothing (LP: #891565)
- HUD is silent to screen readers (LP: #949445)
- launcher background coloring does not get reset when using enter to
activate/start a program (LP: #965079)
- [multi-monitor] [launcher] Drag & drop application to launcher on
primary screen, other launchers not updated (LP: #966239)
- HUD gets activated by Thinkpad USB Keyboard's back and forward buttons
(LP: #968840)
- Unity 2D doesn't load 24 bit icons (LP: #977262)
- Four finger tap does not open the Dash (LP: #978659)
- No icon in launcher entry, after installing software (LP: #980640)
- Menu items displayed incorrectly when window streched over multiples
monitors (LP: #987215)
- [unity-2d-panel] The close button (potentially the others too) can
toggled even when they are not visible anymore (LP: #924264)
- When closing the Dash with the [x] panel button the last windows is not
focused and doesn't allow to use window controls. (LP: #945459)
- [launcher] item hint flickers when hovering between launcher edge and
item (LP: #948383)
- Missaligned progress bar (LP: #980609)
- Launcher tile tooltip appears in wrong screen in RTL multimonitor setups
(LP: #984080)
-- Didier Roche <email address hidden> 2012年4月27日 09:32:40 +0200

Partially fixed only.
Look at the attached screenshot. The icon as a clear blue background.
Look at this same file in Nautilus ou with GIMP or any Image Manipulation Program (/usr/local/share/applications/pendu.desktop), the background is yellow.

Just to clarify - the unity-2d 5.14.0-0ubuntu1 upload does *not* fix this bug, right? It fixes a different bug, where 24bit icons have incorrect colours?

It's not clear to me what the change in the upload is meant to do, and it's not clear to me that it's correct.

Re: lp:~aacid/unity-2d/more_24_bit_stuff
After some testing of this branch, it was found that a very minor visual change was made by the fix. It was near impossible to distinguish with the human eye however. I won't request a SRU for it.

What should we do with this one then? Since the minor visual fix is very minor and not really visible to the user, should I revert this fix for the release?

My understanding of the current state of unity-2d in precise-updates is:
1) If an application specifies a 24bit icon, it will get that icon, rather than a ‘?’
2) If an application specifies a 24bit icon, the colours of the icon will render incorrectly.

Is that correct? If so, I think "24bit icons are rendered with incorrect colours" is (a) a *different bug*, which I think should be filed separately in order to make things as clear as possible, and (b) I'd be happy to accept a fix for that bug in an SRU.

Separate from that is the fact that the fix for the colours being wrong isn't a minimal diff - it contains some refactoring, which makes what it actually does less clear than it could be. AFAICT the fix, as implemented, for 24bit colours being wrong is to not byteswap the 24bit pixmaps, but the diff doesn't make this clear.

So, from my perspective, the way to move this forward is to:
a) File a new bug, describing what the current behaviour of 24bit icons is (AFAICT, the colours are wrong)
b) Make a new unity-2d upload, closing that bug from the changelog.
b*) For bonus points, clean up the diff so that it's clear what it's actually doing, but since I've already gone to the trouble of understanding it, this is optional.
c) I'll accept it into precise-proposed.

Alternatively, don't fix the 24bit colour bug this time, and re-upload a unity-2d without that fix.

Summary I've figured out after some back-tracking - this code has been sitting in our repo for some time now:

This bug is that some 24 bit icons would show up with a ? icon. It's fixed by this MR:
https://code.launchpad.net/~aacid/unity-2d/load_24bit_pixbuf_icons_2/+merge/103311

A MR was later made to automate a test for this fix (instead of manual test):
https://code.launchpad.net/~aacid/unity-2d/load_24bit_pixbuf_icons/+merge/102471

While using the automated test, it pointed out that some 24 bit icon types would show with slightly incorrect colouring. This branch added such a troublesome icon and a fix so the test passed:
https://code.launchpad.net/~aacid/unity-2d/more_24_bit_stuff/+merge/105797
Yes this branch has some refactoring too, it was not made to be SRU specific. In testing last week, we could barely distinguish the visual change this branch performs. As a result, that branch has been reverted for now.

So the first 2 branches should be included in the SRU in my opinion.

We can later create a bug about this colouring bug, attach the fix and merge it. But right now both Albert & I are quite busy. What do you think?
-G

That sounds fine to me. However, I think that those merges are already in the precise-updates version of unity-2d?

The Precise Pangolin has reached end of life, so this bug will not be fixed for that release