KDE application menu does not show icons until user logs out and in again

[probonopd]

When integrating, we should rewrite desktop files to use an absolute Icon= path. This will

• Prevent from rendering issues when the icon size does not match the size of the icon theme directory (at least on some desktops, see below)
• Remove the need to log out and log in again after having installed appimaged/AppImageLauncher and similar tools

[TheAssassin]

Prevent from rendering issues when the icon size does not match the size of the icon theme directory (at least on some desktops, see below)

That cries "temporary workaround" (as in "bad hack"). Absolute paths aren't a solution here, they only seem to "fix" Unity(?)'s behavior... I'm not totally opposed to this change, but we should not sell it as a solution.

Remove the need to log out and log in again after having installed appimaged/AppImageLauncher and similar tools

That doesn't quite remove the need to log out and in on a majority of desktop environments, most prominently KDE. Logging out and in is necessary just for getting the icons to show up anyway, right? New entries will show up in the launchers, they might just lack an icon.

[probonopd]

That cries "temporary workaround" (as in "bad hack"). Absolute paths aren't a solution here, they only seem to "fix" Unity(?)'s behavior... I'm not totally opposed to this change, but we should not sell it as a solution.

Well, the "solution" would be to implement something that replaces all the file-copying. So, let's agree on "workaround" that helps at least Unity and KDE Plasma.

That doesn't quite remove the need to log out and in on a majority of desktop environments, most prominently KDE. Logging out and in is necessary just for getting the icons to show up anyway, right? New entries will show up in the launchers, they might just lack an icon.

Are you sure? On KDE Plasma I don't see any icons in the menus before logging out and logging in again. If I use absolute paths, I see them immediately without logging out and logging in.

Fwiw, I think I heard that Snappy also uses absolute paths for that reason.

[TheAssassin]

Re. KDE Plasma, last time (pre-18.04) I tried it didn't work as intended. Doesn't mean it's not working now. IIRC the issue was in some caching of plasmashell, I filed issues for that.

[probonopd]

Is there something I could test on the latest unstable KDE neon developer edition?

[probonopd]

It does not work for me. If I boot KDE neon developer edition Live ISO with appimaged, then the icons are missing until I log out and log in again.

This is highly annoying to me. Please use absolute paths to the icons, so that it works without having to log out and log in.

[probonopd]

Interestingly, the desktop files in /$HOME/.local/share/applications/ show up correctly without having to log out and log in again, but the stuff in the menu does not. KDE Plasma bug?

[probonopd]

Current neon-devedition-gitunstable-current.iso and appimaged, continuous build (commit 660c916), build 65 built on 2018-12-06 18:38:08 UTC

cc @kossebau

[kossebau]

I vaguely remember the discussion to make Dolphin getting the icons for appimage files when the first appimages are added to the system. IIRC the issue was that Dolphin like many other programs from KDE uses the library kiconthemes, which only watches/scans icon directories which were present when a program like Dolphin was starting and as result the init of libkiconthemes in that process was done.
So when appimaged & Co. copy the icons from the appimage to the user's local icon dirs below .local/share/icons and has to create respective directories first, any process using libkiconthemes which had been started before will not see those icons.
I do not remember what the fix for Dolphin had been. Possibly it does not work with Plasma, that needs to be checked. Nothing I am involved with though, also have no testing setup currently, so one better first gets in contact with active Plasma developers.

[kossebau]

On the actual issue: IMHO using a single pixmap icon file (if using an absolute path) will not be a good solution, and runs the chance to make the integration of appimages inperfect, in the worst case resulting in appimage apps always detectable by being the ones with blurry icons.

Icons for applications can be shown in lots of different sizes, and having to downscale (or upscale for HiDpi) a given pixmap is not the best. Many icons have dedicated variants for smaller sizes (less details, adapted pixelgrid aligning). Which also means a single SVG icon file is not the solution to escape to, the same applies there as with prerendered pixel image files.

It would be better to fix the workspace to pick up new icon versions installed to user local system dirs at runtime. Not picking up those is broken in general, not only in the context of appimages.

[probonopd]

It would be better to fix the workspace to pick up new icon versions installed to user local system dirs at runtime. Not picking up those is broken in general, not only in the context of appimages.

Agree. It'd be the right thing to do to get this fixed in KDE but I don't know where to even start. And blurry icons are better than no icons...

With "workspace" we mean the KDE launchers/menus (all three of them) but not the file manager (Dolphin) (where it works already).

[azubieta]

I'm about to rewrite this functionality in the C++ implementation. I'll keep the old workflow (icon name only) until a solution is found.

[probonopd]

Agree. We should, however, inform the KDE team through their appropriate channels about the issue.

Added a comment at https://bugs.kde.org/show_bug.cgi?id=397109#c6. Maybe @kossebau can help to get the attention of the right people within the Plasma team. Thank you.

[kossebau]

Current neon-devedition-gitunstable-current.iso and appimaged, continuous build (commit 660c916), build 65 built on 2018-12-06 18:38:08 UTC

@probonopd Any chance you started the Dolphin instance only after those appimages had been added (and triggered the system integration of appimaged, incl. creating the .local/share/icons/hicolor directories)?

Could you repeat what you did, with a clean system without .local/share/icons/hicolor, and an already running Dolphin instance showing the applications directory where the appimages files are then placed?

[probonopd]

It's a bit hard to understand what happens in which order during system startup, but this is my setup:

• Neon devedition unstable Live ISO (I get the same behavior with other KDE based distros)
• Booted directly from Live ISO using SystemImageKit
• appimaged is "installed" via a SystemImageKit ExtensionImage (makes it appear as if it was "installed" on the system)
• The AppImages reside in /Applications on the USB medium that also contains the Live ISO
• I assume that the icon directories are already present at the time when KDE Plasma is loaded since we explicitly generate them - apparently this has helped in the case of Dolphin (not sure whether Dophin still needs this) but not for the menu launchers https://github.com/probonopd/SystemImageKit/blob/8e598ea65dde5a6aca3ac9e8b43ae4323584a7f8/boot/bin/generate-appimaged-extension#L31-L42
• appimaged has probably detected the AppImages only after KDE Plasma was already running

Do you want me to repeat this without the directories being pre-created?

[kossebau]

I assume that the icon directories are already present at the time when KDE Plasma is loaded since we explicitly generate them

Hm, I am confused by the comment in the linked code:
"# It looks like it is too late here to populate skel, hence this DOES NOT WORK"

So right after neon having been started, i.e the Plasma workspace being up, does the directory ".local/share/icons/hicolor" exist before the first appimage is added? (sorry, no time yet to try to reproduce)

[probonopd]

I have commented out the code I linked that pre-generates the $HOME/.local/share/icons/hicolor tree. Dolphin still does show the icons for the desktop files in $HOME/.local/share/applications/ (so maybe that was fixed in the meantime).

appimaged creates the $HOME/.local/share/icons/hicolor tree when it starts up. So yes, this directory exists before appimaged tries to copy icons there.

The only thing is that I don't know when in the overall system startup this happens exactly ( I don't know how systemd would tell me).