Invalid 'X-FullPathIcon' entries in '/usr/share/applications'

[maro]

Today I stumbled over the fact that '/usr/share/applications' contains .desktop files that have invalid entries for 'X-FullPathIcon':

Code: [Select]

tc@box:/usr/share/applications$ grep 'X-FullPathIcon=' *.desktop | sed 's#:.*=# #' | while read FILE ICON ; do [ -f $ICON ] || printf "no %-37s for %s\n" $ICON $FILE ; done
no /usr/share/pixmaps/tc/appbrowser.png  for tinycore-appbrowser.desktop
no /usr/share/pixmaps/tc/logo.png        for tinycore-appsaudit.desktop
no /usr/share/pixmaps/tc/aterm.png       for tinycore-aterm.desktop
no /usr/share/pixmaps/tc/cpanel.png      for tinycore-cpanel.desktop
no /usr/share/pixmaps/tc/power.png       for tinycore-exit.desktop
no /usr/share/pixmaps/tc/logo.png        for tinycore-wbar_exclude.desktop

We might not have seen this causing problems as the 'SystemTools' menu does not use icons, and for "wbar" the icon entries in '/usr/share/wbar/dot.wbar' are correct.

Now, this made me wonder if having those hard-coded entries in '/usr/share/wbar/dot.wbar' is still appropriate in light of the tendency to make use of .desktop files: I thought that trimming back '/usr/share/wbar/dot.wbar' to just the first 4 lines and injecting some appropriate 'wbar_update.sh' commands in '/usr/bin/wbar_setup.sh' might be more consistent.

For a rather "ad hoc" test I used:

Code: [Select]

--- wbar_setup.sh-orig
+++ wbar_setup.sh
@@ -2,9 +2,18 @@
 2>/dev/null read TCEDIR < /opt/.tce_dir || exit 1
 TCEWBAR="/usr/local/tce.icons"
 [ -e "$TCEWBAR" ] && sudo rm -rf "$TCEWBAR"
-sudo cp /usr/share/wbar/dot.wbar "$TCEWBAR"
+head -4 /usr/share/wbar/dot.wbar | sudo tee "$TCEWBAR" > /dev/null
 sudo chown root.staff "$TCEWBAR"
 sudo chmod g+w "$TCEWBAR"
+SYSAPPS=/usr/share/applications
+FREEDESK=/usr/local/share/applications
+[ -d "$FREEDESK" ] || sudo mkdir -p "$FREEDESK"
+for ENTRY in exit aterm cpanel appbrowser ; do
+    [ -f "${FREEDESK}/tinycore-${ENTRY}.desktop" ] \
+        || sudo ln -s "${SYSAPPS}/tinycore-${ENTRY}.desktop" \
+            "${FREEDESK}/tinycore-${ENTRY}.desktop"
+     wbar_update.sh "tinycore-${ENTRY}"
+done

 INSTALLED=/usr/local/tce.installed
 ONDEMAND="$TCEDIR"/ondemand
As this change would cost a few CPU cycles I wanted to find out how badly it would do. I ran each version via a loop 100 times and divided the (hand-stopped) result by 100: the original took ca. 0.1 sec and the changed version 0.5 sec (using QEMU 0.11.1 on a not particular speedy WinXP host). So that might be notiecable as the "$ICONS"_setup.sh call is in 'startx' and would therefore delay the start of the X server by a fraction of a second. I guess this could be partly mitigated by moving the execution of the script into '~/.xsession' instead.

Well, all up this is maybe a matter of taste and depends on how much weight one puts on consistency. I for one would possibly  put the names of the four .desktop files in a text files, from which they would be read during the 'wbar_setup.sh' execution (instead of hardcoding them there).

I can imagine some further improvements are possible: As I had to do this work-around for the fact that 'wbar_update.sh' needs for .desktop files to be in '/usr/local/share/applications'. But in the end I only went for the minimal changes shown above.

[roberts]

Interesting as LXDE ,my freedesktop DE test environment, the icons are found. As I don't use any freedesktop, to bloated for me, I had not looked further. I had no plans to make the base system icons variable or removing base icons when wbar is in use.

Enumerating the basic icons in code and then relying on freedesktop specifications versus starting with a defined wbar static set, not relying on parsing freedesktop specs,  is a benefit?

[maro]

Enumeration the basic icons in code and then relying on freedesktop specifications versus starting with a defined wbar static set. not relying on parsing freedesktop specs,  is a benefit?

Well, I'm was not suggesting that it is a serious flaw to have the static setup. I guess I got triggered by this question, and thought initially that with the .desktop files around the 'wbar' would be now also go through a .desktop file driven configuration. WRT the enumeration in the loop, I guess I had already hinted in my closing remark what I'd perceive to be a better solution.

Your remark regarding 'LXDE' is interesting: I have not used a non-default WM for a while, and just had a quick look. As it turns out 'LXDE.tcz' comes with it's very own set of icon files (in '/usr/local/share/pixmaps') and .desktop files (in '/usr/local/share/applications') for 'appbrowser' and 'cpanel'.

[roberts]

It would make sense to me if multiple non-freedesktop ICON systems were supported, but currently not. Only one, wbar, is supported therefore to continually process static data is not something I will opt for. With static data it is far more efficient to preprocess and than to repeatedly process unchanging data. I know that there are some that want me to make it easier to un-brand Tiny Core, but I don't see where that is in the interest of the project. All sources are provided for those that wish such.

Seems LXDE extension needs to be cleaned up. There was so much pre-testing during the development of freedesktop support with claims of searching subdirectories support. 

Anyway it is good to get this addresses during an rc. Hopefully bmarkus will update LXDE(2) so that it can be properly configured for Tiny Core..

[roberts]

I looked at LXDE2 and there are duplicates for appbrowser, cpanel, and exit embedded in the extension.  Both base and extensions items appear in system tools menu. You can see by the AppsBrowser (base) versus appbrowser (extension). Freedesktop does not use X-FullPathIcon, only wbar and as wbar is prebuilt static, while inconsistent not really in use. The tc subdirectory has been removed from base desktop items to be consistent. The LXDE(2) extensions need duplicates as specified removed.

[bmarkus]

Original title of topic is:

Invalid 'X-FullPathIcon' entries in '/usr/share/applications'

X-FullPathIcon is not used by Xfce4, LXDE or LXDE2 at all, these are purely for TC itself. Regarding mentioned DE's you can do with such entries whatever you want without influencing FreeDesktop compliant systems.

Reviewing TC base related .desktop items is now after environment is stable is another topic. However I agree, it is the time to see what changes are needed either in base or DE's.

[roberts]

While the title is as you have bold faced the final result is that there are base duplicates (appbrowser, cpanel, and exit) in the LXDE2, and possibly other freedesktop, extensions that need to be removed.