desktop icons with relative path to .desktop file

[Duncan]

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