Erroneous icons on running application tabs on panel

[L4wnmower]

E.g. I'm currently seeing two separate chromium tabs, one featuring the R icon, the other featuring the midnight commander icon. Have seen similar issues with mathematica tabs feturing the R icon. How does the panel attempt to match a suitable icon?
Can it be a configuration issue?

[spl237]

Unlike under X, Wayland has no direct mechanism to associate an application with its icon. The panel runs some heuristics to try and guess what the correct icon should be, and it gets it right most of the time, but it's not infallible. Can you please provide a screenshot of what you are seeing (so I can identify the icons) and the output of "ps ax" (so I can identify application IDs), and I can then see if there is an obvious case being missed somewhere?

[L4wnmower]

Chrome tabs running Gemini and DeepSeek respectively are installed as Chromium apps. I suspect this possibly confusing the heuristic algorithm. Mathematica on the other hand is stock OS app.
Screenshot: https://i.imghippo.com/files/LyEA4345o.png

PID 4931 is Chromium window running Gemini (as a webapp). Cannot pinpoint DeepSeek's PID, must be another Chromium ps
ps ax: https://www.mediafire.com/file/zy1oq6ielexhuc4/proc.txt/file

Double checked, same issue with all Chromium installed webapps

[spl237]

Thank you.

I've just tried Mathematica here, and I get the correct icon, so something weird is going on with your system.

Do you recognise the R icon? What app is it supposed to be associated with? Ditto the other icon which is displaying for Chromium? It would be really helpful if you can work out a) which package installed those icons, and b) which icon files they actually are. They are almost certainly PNG files somewhere under /usr/share/icons, probably in the default hicolor subdirectory, which is the default icon theme.

Also, can you please tell me how you installed Gemini and DeepSeek as Chromium apps? Were they installed from apt, or by some other mechanism?

As I say, I don't see this behaviour on my system, so as much info as possible to help me reproduce it would be appreciated!

TIA.

[L4wnmower]

First of all, thank you for your brilliant work & apologies for my lacking knowledge.
Just another IT amateur naval architect.

I do recognize it. It's the R language icon (Programming->R.desktop) that lives in /usr/share/icons/hicolor/48x48/apps/rlogo_icon.png. I looked for it and it's part of the r-base-core package that was installed late of December together with a big bunch of other stuff. Pretty sure (not explicitly found in dependencies but , say, 80% sure) it was installed with Sage (the sagemath package). The other icon is from Midnight Commander (aka mc, Accessories -> mc.desktop) living in /usr/share/icons/hicolor/64x64/apps/MidnightCommander.png. Both apps are from the stock apt repos. I verified the internal existence of the icons by dpkg-deb -c-ing them. The .debs respectively are

r-base-core_4.2.2.20221110-2_arm64.deb
mc-data_3%3a4.8.29-2_all.deb ->(listed version is `3:4.8.29-2`)

All the Chromium apps were installed by Chromium's "installation" mechanism (vd. top-right 3dots -> Cast, Save & Share -> Install ). I'm completely unfamiliar with Chromium's internals (src) - from appearances only, this action:

1. Creates a chrome-apps.directory in ~/.local/share/desktop-directories/ if one not already there
2. Creates a suitable chrome-<Unique App ID hash>-Default.desktop in ~/.local/share/applications/
3. Similarly, creates a copy of latter in ~/Desktop/

Skeleton of chrome-<Unique App ID hash>-Default.desktop is of the form:

#!/usr/bin/env xdg-open
[Desktop Entry]
Version=1.0
Terminal=false
Type=Application
Name=<App Name, e.g. Gmail>
Exec=/usr/bin/chromium --profile-directory=Default --app-id=<Unique App ID hash>
Icon=chrome-<Unique App ID hash>-Default
StartupWMClass=crx_<Unique App ID hash>

The chrome-apps.directory contents is:

[Desktop Entry]
Version=1.0
Type=Directory
Name=Chromium Apps
Icon=$HOME/.local/share/icons/chromiumapps.png  #Edited this because originally category did not have proper icon
Comment=

Unsure about the whole icon registering process. Clearly your knowledge domain.
Is it done just by suitably dropping a .png in the right place (like ~/.local/share/icons/ or /usr/share/icons or /usr/share/pixmaps) or is there an additional registering mechanism?

In the mean time, I'l check also what happens if I switch to X11. Same or not?
Edit: No. In X, icons are correct. Actually, Chromium apps feature the actual app (URL) icon

Regards

[spl237]

OK, that's all really helpful - thank you. I'll have a dig about - hopefully some time this week - and see what I can work out.

[spl237]

Right...

I understand the problem, and I think I have fixed it.

The issue was that Chromium applications are installing their desktop files in a completely different directory from all other applications, and that directory was not on the search path which is used by the panel to find the desktop files, from which it looks up the icons to display.

This was being compounded by the two packages you had installed, which install desktop files with unhelpfully short names - in one case, one character only. This meant that the "r" desktop file ended up being matched as a fallback by any application with an "r" in its name - such as "chromium".

I have modified the search path to include that used for Chromium apps, and made some tweaks to the panel code to interpret this path correctly. The relevant packages are being uploaded now, and should be available on an apt update in the next few hours.

The only outstanding issue is why the icon for Mathematica was incorrect - it was clearly getting the same "r" fallback, as "wolfram-mathematica" contains an "r", but I do not understand why it was getting to a fallback case, when it should have been able to match the correct desktop file and icon. It may be that the problem is fixed by this set of fixes - in which case great - but if not, please let me know and I may need to ask you for more debugging. But I am reasonably certain that if it that is the case, it will be due to some weirdness or corruption on your particular image and not a more general problem.

[L4wnmower]

Testing 0.93...
Indeed Chromium apps have been fixed.
Mathematica still shows the R icon.
Also have discovered the R icon hijacks the shutdown dialog as well.
Would it make sense to force a rename on the R .desktop file to something more intuitive? (e.g. rlanguage.desktop)
Edit: That trick worked. Force renaming R.desktop to Rlang.desktop frees Mathematica etc.
What would you like me to look for in search for extra dbg info?
Edit: How does the code decide when to go for the fallback or not?

[spl237]

OK, progress...good!

The fact that you were getting corruption on the shutdown icon as well suggests that something in your icon hierarchy or the desktop files is not right; I can't repeat any of those issues here.

What is the output of "sudo find / -name wolfram-mathematica.desktop"?

What is the output of "sudo find / -name wolfram-mathematica.png"?

What is the output of "export | grep XDG_DATA_DIRS"?

Thanks.

[spl237]

Edit to the above - I have now repeated the shutdown icon corruption - that's just because said application has no associated icon; that's easily fixed. (But really, the authors of r who decided to give a file a single letter name did not fully consider the implications of doing so!)

But I still can't see why mathematica would be displaying the wrong icon.

[L4wnmower]

Helllo,

>sudo find / -name wolfram-mathematica.desktop
/usr/share/applications/wolfram-mathematica.desktop
find: ‘/run/user/1000/gvfs’: Permission denied
find: ‘/run/user/1000/doc’: Permission denied
/media/george/rootfs/usr/share/applications/wolfram-mathematica.desktop

(Last one is from the SD card that holds a different instance of RPiOS)

>sudo find / -name wolfram-mathematica.png
/usr/share/rp-prefapps/wolfram-mathematica.png
/usr/share/icons/hicolor/128x128/apps/wolfram-mathematica.png
/usr/share/icons/hicolor/64x64/apps/wolfram-mathematica.png
/usr/share/icons/hicolor/32x32/apps/wolfram-mathematica.png
find: ‘/run/user/1000/gvfs’: Permission denied
find: ‘/run/user/1000/doc’: Permission denied
/media/george/rootfs/usr/share/rp-prefapps/wolfram-mathematica.png
/media/george/rootfs/usr/share/icons/hicolor/128x128/apps/wolfram-mathematica.png
/media/george/rootfs/usr/share/icons/hicolor/32x32/apps/wolfram-mathematica.png
/media/george/rootfs/usr/share/icons/hicolor/64x64/apps/wolfram-mathematica.png

(Ditto)

>export | grep XDG_DATA_DIRS
declare -x XDG_DATA_DIRS="~/.local/share:/usr/local/share:/usr/share/raspi-ui-overrides:/usr/share:/usr/share/gdm:/var/lib/menu-xdg:/home/george/.local/share/flatpak/exports/share:/var/lib/flatpak/exports/share:/usr/local/share:/usr/share"

I'm considering sending an e-mail to the maintainers of each package (R & mc -> the e-mail addr. that usually appear with sudo apt-cache show) to try presenting the issue. Understandably, your opinion as an expert would weigh in much more heavily than mine.

Haven't really messed with stock icons, beside adding (shame on me) some custom ones to ~/.local/share/icons, for which I tried to have distinct names.
https://i.imghippo.com/files/gK3232I.png

Thank you

[spl237]

Helllo,

>sudo find / -name wolfram-mathematica.desktop
/usr/share/applications/wolfram-mathematica.desktop
find: ‘/run/user/1000/gvfs’: Permission denied
find: ‘/run/user/1000/doc’: Permission denied
/media/george/rootfs/usr/share/applications/wolfram-mathematica.desktop

(Last one is from the SD card that holds a different instance of RPiOS)

Ok, that looks fine.

>sudo find / -name wolfram-mathematica.png
/usr/share/rp-prefapps/wolfram-mathematica.png
/usr/share/icons/hicolor/128x128/apps/wolfram-mathematica.png
/usr/share/icons/hicolor/64x64/apps/wolfram-mathematica.png
/usr/share/icons/hicolor/32x32/apps/wolfram-mathematica.png
find: ‘/run/user/1000/gvfs’: Permission denied
find: ‘/run/user/1000/doc’: Permission denied
/media/george/rootfs/usr/share/rp-prefapps/wolfram-mathematica.png
/media/george/rootfs/usr/share/icons/hicolor/128x128/apps/wolfram-mathematica.png
/media/george/rootfs/usr/share/icons/hicolor/32x32/apps/wolfram-mathematica.png
/media/george/rootfs/usr/share/icons/hicolor/64x64/apps/wolfram-mathematica.png

(Ditto)

As does that - although I do wonder if the additionally mounted drive is somehow making a difference - if you remove that drive and reboot, does the problem persist?

>export | grep XDG_DATA_DIRS
declare -x XDG_DATA_DIRS="~/.local/share:/usr/local/share:/usr/share/raspi-ui-overrides:/usr/share:/usr/share/gdm:/var/lib/menu-xdg:/home/george/.local/share/flatpak/exports/share:/var/lib/flatpak/exports/share:/usr/local/share:/usr/share"

OK, I cannot see why it would make a difference, but that path is a bit broken. /usr/local/share and /usr/share both appear twice, which may be causing problems. I'm also not sure what flatpak might be doing in this case.

This path is initially set by the file /usr/bin/setup_env, which runs at desktop start. However, this just prepends to anything set by the flatpak installer. So I suspect something in the flatpak process has added the terminal /usr/local/share and /usr/share at the end, and I think those need to go. But as I don't know what is adding them, I'm not sure how to suggest removing them.

In order to confirm that this is indeed the problem, please try the following:

pkill respawn
pkill wf-panel-pi
declare -x XDG_DATA_DIRS="~/.local/share:/usr/local/share:/usr/share/raspi-ui-overrides:/usr/share:/usr/share/gdm:/var/lib/menu-xdg"
wf-panel-pi

(To restore the original configuration with the flatpak additions, you just need to reboot - the above lines will just temporarily restart the panel with a clean search path.)

If the Mathematica icons are now correct - and I suspect they will be - then it looks as if something flatpak is doing is causing the icon search heuristics to fail.

[L4wnmower]

Thanks!

In order to confirm that this is indeed the problem, please try the following:

pkill respawn pkill wf-panel-pi declare -x XDG_DATA_DIRS="~/.local/share:/usr/local/share:/usr/share/raspi-ui-overrides:/usr/share:/usr/share/gdm:/var/lib/menu-xdg" wf-panel-pi

(To restore the original configuration with the flatpak additions, you just need to reboot - the above lines will just temporarily restart the panel with a clean search path.)

If the Mathematica icons are now correct - and I suspect they will be - then it looks as if something flatpak is doing is causing the icon search heuristics to fail.

Tried it, but results still ambiguous. If I reintroduce the perturbation of R.desktop, Mathematica's icon still gets hijacked, even with the clean path. The decisive factor is renaming the R.desktop into something longer and unique.

There are two flatpaks installed currently. One is Peazip, the other Kdenlive. This version of Kdenlive is very recent and offers full wayland support. It's a bit heavy on it's own dependencies and relies on it's own (and much more recent than stock) version of Mesa. In order to check if the flatpaks are to blame or not, I'l try installing R on another different OS instance, to see what happens.

I noticed the fixed icon of the shutdown dialog as well. Nice!

Reverting with testing results... done

I was on a Pi400. Tried again on the 400 with another OS instance. No Kdenlive, but with the Peazip flatpak. Installed r-base-core and results are the same. On the other hand, on a Pi5 with OS updates until 31/10/2025 (pre-labwc) no hijacking with R. This machine had no flatpaks installed at all. Just to be sure, I updated to current version and checked again: still no hijacking.
What remains unclear, is if this is caused by a specific flatpak (Peazip) or by installing flatpaks in general. Will have to test this on a pristine image, probably during the weekend.

Something that is currently troubling me on the Pi5 is that I started getting a dmesg error:

[    0.695700] rp1-pio 1f00178000.pio: error -ENOENT: failed to contact RP1 firmware
[    0.705183] rp1-pio: probe of 1f00178000.pio failed with error -2

[spl237]

In that case, there probably isn't a great deal more I can do at this stage - I have tried installing flatpak itself here, but that was not sufficient to trigger the problem.

One change I can make is to add some code to prevent single-letter filenames being matched in the fallback case, but it feels more like a hack than a fix; nonetheless it might be worth a go, so will look at doing so.

But if you can find a reliable way to repeat the problem from a clean image, then I can have another look.

[L4wnmower]

Update: I tried hard using a clean RPiOS install, but it appears it's not that easy to pinpoint all the parameters involved. It cannot be attributed either to flatpak itself or the Peazip flatpak. I'm out of ideas :(.
Should we keep the bug open, or close it until we can pinpoint all the causes?

[spl237]

I'm happy to leave it open as a placeholder for now, but given neither of us can repeat it, unless it re-occurs in the not too distant future, I'm inclined to put it down to one-off corruption of the image. I really can't see any way it can happen in normal operation.