search

raspberrypi-ui / wf-panel-pi

MIT License
4 stars 6 forks source link

140 debian applications broken by menu update (no icon in applications menu) #22

Closed Botspot closed 1 month ago

Botspot commented 1 month ago

This issue is based on the previous issue here: https://github.com/raspberrypi-ui/wf-panel-pi/issues/21

While the detection of explicit icons paths was restored in commit https://github.com/raspberrypi-ui/wf-panel-pi/commit/d7694198be1ee77dcac8b0373771c43decc221af, the menu will still fail to detect a suitable icon for .desktop files that specify an explicit filename without a full path.

This may seem like an edge case. The functionality is not guaranteed in the Freedesktop spec, and I agree with you that it seems like an ugly hack. In fact I only even noticed it thanks to Netsurf web browser. To check if this was unique to Netsurf or if it affected other applications, I wrote a script to download every apt package containing a .desktop file and check for the presence of this specific icon reference style. Here is the script.

#!/bin/bash
#dependencies
sudo apt install -yf apt-file
mkdir ~/desktop-files
IFS=$'\n'
cd "$(mktemp -d)"
apps="$(apt-file search /usr/share/applications | awk -F ': ' '{print $1}' | uniq)"

for app in $apps;do
  rm -rf extracted *.deb
  apt download $app
  mkdir extracted
  dpkg-deb -x *.deb extracted
  cat extracted/usr/share/applications/* > ~/desktop-files/$app.txt

done
rm -rf extracted *.deb
cd ~/desktop-files
grep '^Icon=' -r | sort -u | sed 's/\.txt//g ; s/:I/: I/g ; s/^/- /g' | grep '\.' | grep -v '/\|\..*\.\|\..*: \|\..$\|application-vnd\.iccprofile'

This was the output.

It found 140 affected packages out of the 2791 total packages that have a menu launcher, meaning that this update to the menu breaks the icon for about 5% of all GUI applications, or 1 in 20.

This is far more significant than I had expected. I had predicted the number of affected apps would be well under 1%.

With these findings in mind, I can think of a few solutions:

  1. Patch every affected package upstream to have them use full paths or remove the file extension. (unrealistic)
  2. Patch the menu to ignore the file extension and search for the icon in the icon theme.
  3. Implement a simple search algorithm for at least /usr/share/pixmaps and /usr/share/icons to look for the filename.
  4. Restore the libfm searching algorithm, but only use it if a file extension is detected. (partially restoring functionality that was removed in commit https://github.com/raspberrypi-ui/wf-panel-pi/commit/efafe5800adbf76869c8b7f1e03b6cf6dd4d4622)
  5. Do nothing and still claim it is not worth fixing. I would hope that you choose not to do this.
spl237 commented 1 month ago
  1. Do nothing and still claim it is not worth fixing. I would hope that you choose not to do this.

I'm afraid that is exactly what I am going to do. As far as I can tell, the use of an explicit icon file name without a path is not supported by the FreeDesktop spec, so these applications do not conform to it - I suspect most of them are rather old and unmaintained. I also suspect that on various other distros, they would also get no icon loading, because the handling of anything other than a fully-specified path is down to the implementation, and any fix for this is going to involve an ugly hack which is not supported by the spec.

Most people will never install any of these applications on Pi (or, by the look of most of them, any other distro...) so I feel that this very much is an edge case that will affect a very small number of icons on the system for a very small number of users. If that turns out not to be the case in reality, I can revisit this, but for now, we will be following the FreeDesktop spec and supporting full paths and icon lookup in the theme only.

spl237 commented 1 month ago

On reading the FreeDesktop spec again, it seems that installing icon files in /usr/share/pixmaps is (or at least used to be) legitimate, and in the case of Netsurf, that is the only place it puts an icon file anyway.

So I am going to add a fallback option so that if an explicit path is not specified and the named icon is not found in the theme, then I will look for that named icon in /usr/share/pixmaps. I suspect this will fix the vast majority of the cases above, which look like old and unmaintained apps which may have used this earlier location for icon installation.