Alexander Puchmayr posted on Fri, 02 Jun 2023 13:04:46 +0200 as excerpted: > Hi there, > > I'd like to use a shared nextcloud folder to deploy clickable shortcuts > to certain programs with some pre-defined arguments (e.g. urls to some > web-sites, > programs which need some extra arguments such as a session specifier or > the like). > > Using .desktop files seems to be the perfect solution for this, but I'd > also like to have individual icons for those desktop files, for example > different icons for different web sites. So the idea is to create a > .icons directory inside the shared folder from nextcloud and use > ./.icons/<someicon> as relative path with the .desktop file as reference > directory. > > https://unix.stackexchange.com/questions/428992/why-do-freedesktop- desktop-files-not-allow-relative-paths > explains some reasons why this is not possible, but I don't see another > way of getting what I want. Absolute paths are not possible (the > nextcloud shared folder is located in the user's home directory), and > the target audience for my setup is not expected to be allowed or able > to install anything on their computers. So for this problem, the only > solution is to place the icons inside the shared folder.
Thanks for already doing some of the research. Looking at it, it should be possible to do what you want (unless there's further site-policy restrictions you didn't realize were apropos and thus didn't mention that prevent it), but from this angle, it seems you're fighting the icon themes spec (seeing what it prevents, the spec is linked repeatedly from that stackexchange page) rather than trying to work with it (using the flexibility it allows) to do what you need. Quoting the spec (directory layout page) https://specifications.freedesktop.org/icon-theme-spec/latest/ar01s03.html >> By default, apps should look >> in $HOME/.icons (for backwards compatibility), >> in $XDG_DATA_DIRS/icons and >> in /usr/share/pixmaps >> (in that order). That immediately suggests two different possibilities, plus a third simpler one (described first below) I doubt will work but would have to try to know for sure (it's not in the spec but could be in some implementations): 1) Simplest if it works so worth a try but probably won't: Try the traditional Unix-y ~/ denotation for $HOME in the icon path. I guess I'd call that half-way between absolute and relative. With the nextcloud dir a subdir of $HOME, presumably a specific subdir always located at the same spot relative to $HOME, if it works... but probably not. While you're at it, might as well try $HOME as well, which would imply that other environmental variable values should work too, tho I'd be even more surprised if that works. 2) Should work by implementation, but could well be impractical for you: You mention that users are not expected to be able to install anything, but it's ambiguous whether that extends to ~/.icons/ (aka $HOME/.icons/ ) or not. If it's read-only (you don't what users overriding icons that way), what about making that a symlink (which /can/ be relative) to your desired shared dir, presumably starting with /etc/skel/ (aka the template $HOME, which you may handle differently) so it's setup automatically for all new users? If possible, that should "just work". 3) Should work by implementation, and most likely to be practical, tho with a bit more complexity: Take advantage of that $XDG_DATA_DIRS/icons entry. In particular, note that XDG_DATADIRS is plural... Here's the kde page with some detail and a link to the freedesktop.org spec (see the freedesktop.org compliance section): https://userbase.kde.org/KDE_System_Administration/Environment_Variables In particular, $XDG_DATA_DIRS is a colon-separated list with defaults if unset/empty of /usr/local/share:/usr/share . Of course that means you can extend the list by setting and exporting the variable (if it's already set, your distro likely uses it so you'll likely want to add to the list, not replace it). FWIW I routinely use/extend the various $XDG_* variables here (tho in a home I'm my own sysadmin, with myself as the primary user with three role- based user accounts, user/admin/root, context, and I've never had to actually try it with icons as you are) and can say with a certainty it's quite a flexible setup, if you're willing to work with it. Presumably after adding the desired dir to the $XDG_DATA_DIRS list in the desired ordered location, you'd create the icons/hicolor/ subdir (hicolor being the default fallback theme, or substitute whatever company theme or the like) and place your desired icons within it so they'll be in the search sequence, as appropriate and as described in the icon-theme-spec. Then you can simply point to them by unpath-ed name in the *.desktop file and it should "just work" (after a reboot or otherwise ensuring the new envar setting is in the environment as kde/plasma sees it, of course =:^) . The big caveat here is of course the assumption that you can set and export XDG_DATA_DIRS deployment-wide as appropriate for your site/policy, but given the scenario you've described and the privs that already requires, I don't believe that's an unreasonable assumption. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
