since april or so on my arch linux system, when logged into a session that isn’t plasma (i use gwenview with awesome wm and also tried mate, on both my existing and a new user), the “open in new window” menu option does nothing when activated and there are no applications listed under “open with”. manually typing a program name each time still works as expected
this doesn’t appear to be an issue with gwenview directly. the last version i know this bug was absent from was 24.02.1, however, if i held just gwenview at that version, the bug appeared still. i’m guessing the bug is in one of its dependencies. the bug is absent if using only packages from the arch linux package archive snapshot from march 31, 2024
Can you also check what is configured in System Settings → Default Applications → File Associations → image ? Open the image node and select any (common) image format and check if you see any entries there: this is the list you should see in the “Open with” menu. If you don’t see anything under “Open with” I expect you won’t see anything listed for images in File Associations.
It is possible that the “Open in new window” menu option actually triggers the “Gwenview” entry from File Associations, though I couldn’t reproduce the problem by removing “Gwenview” from the File Associations.
Also, can you please post the output from running the following command in a terminal:
under “Application Preference Order” it says “None” for all image formats (and all the non-image formats i cared to check). it lets me add “gwenview” to that list by typing it manually (using the same ui in which i type it manually within gwenview itself), but then when i press “Apply” it goes back to saying “None”. gwenview’s behavior is unchanged
Can you please check if you have the file mimeapps.list in your ~/.config directory?
Make sure you have write permissions for that file - i.e. that both ~/.config and mimeapps.list are owned by you and in the Permissions properties it has Owner: can view & modify.
just now, i found a post (which i’d have linked, but apparently links aren’t allowed on here?) that recommended installing the archlinux-xdg-menu package and running
XDG_MENU_PREFIX=arch- kbuildsycoca6
this did in fact work around the bug, but i don’t understand what’s going on well enough to know what i need to configure to avoid manually running commands in the future
No having an up to date system configuration cache could definitely be the reason you are having a bad configuration day.
The system configuration cache is supposed to be rebuilding automatically every so often - basically almost everything you do in Plasma is supposed to trigger a ksycoca refresh. The most common problem with ksycoca is that it looks at the time stamps of configuration files it needs to consider and will not run a rebuild if a configuration file has a time that is earlier than the system configuration cache itself. In several - slightly weird - situations, time stamps are not updating correctly for files (under NixOS, immutable operating systems and a few other edge cases) and that messes up the sycoca logic and you will need to run kbuildsycoca manually to force it to refresh the cache.
the environment variable was critical. simply running kbuildsycoca6 was not sufficient. for now i’ve just put it in my .profile. maybe that’s all i need to do for now unless i keep noticing this issue. thanks for your help!
Huh, yea, I missed that - sorry. So this could be the real issue - Plasma expects that XDG_MENU_PREFIX will be set to plasma- because the Plasma applications.menu file that controls where interesting desktop settings folders are, is supposed to be /etc/xdg/menus/plasma-applications.menu. If you don’t have that file, and you have a file called /etc/xdg/menus/arch-applications.menu where all the settings are - then that would also explain the problem (i.e. its not the timestamps).
Maybe just set the environment variable in your profile or PAM environment and that should be it?
this actually didn’t resolve it after all because there’s a separate hook (update-desktop-database.hook) that undoes the work of that one and i’m not sure how to make them execute in a specific order or fix the original hook. so, i guess i’m doing it manually for now
i don’t know, but it runs /usr/bin/update-desktop-database --quiet, and after it runs, applications are no longer listed in gwenview until i run kbuildsycoca6 again (with XDG_MENU_PREFIX=arch-). i assume i could edit it to use the env command like i did in my custom hook but i would rather figure out why it’s doing that in the first place and haven’t gotten to it yet
The update-desktop-database command only updates the MIME cache file at /usr/share/applications/mimeinfo.cache - if it is updated incorrectly it might also cause the issue you reported of “no applications listed under “open with”” for image files. You can run it manually (with sudo) and then check the content of the /usr/share/applications/mimeinfo.cache and see if it messed it up - for example, on my system after this runs, the mime cache file has this line to enable Gwenview support for the image/png format:
after upgrading packages, i noticed today that update-desktop-database no longer empties gwenview’s applications menu, so i no longer have a package hook that breaks things. bug seems to be resolved. thanks for your help!
