Docklike ignores user overrides of global .desktop files
Copied from #18 (comment 39885).
Managing windows and .desktop files is hard
I'm no longer sure if splitting AppInfos::search()
is the best design. It's viable (probably no better or worse in practice than the current design), but I don't know if "windows have app IDs and pinned apps have absolute paths" is the right solution. KDE plasmashell has at least 3 types of pinned launchers! On my system, /home/nyanpasu64/.config/plasma-org.kde.plasma.desktop-appletsrc
(link) contains applications:firefox.desktop
, preferred://filemanager
, and file:///var/lib/flatpak/exports/share/applications/org.audacityteam.Audacity.desktop
. I'm not sure if it's necessary to support all these different URI types.
I don't think it's possible for any dock at all (Docklike, plasmashell, etc.) to use WM_CLASS alone to identify whether a window corresponds to a systemwide app or a Flatpak app. KDE plasmashell lets me separately pin Flatpak Audacity (an absolute file:///
URI) and system Audacity (applications:audacity.desktop
), but mistakenly associates Flatpak Audacity with system Audacity.
Docklike ignores user overrides of global .desktop files
Right now, when scanning .desktop files and mapping from windows to .desktop files, Docklike prefers global .desktop files over user-specific overrides! When I run pavucontrol-qt, then right-click the icon and select "Edit Launcher", it edits the system launcher (where pavucontrol and pavucontrol-qt have the same visible name) and not my user-specific renamed launcher. I think this is because /usr/share/applications/... is sorted after /home/.../.local/share/applications/... at https://gitlab.xfce.org/panel-plugins/xfce4-docklike-plugin/-/blob/master/src/AppInfos.cpp#L105.
How should we should prioritize global, Flatpak, and user-specific .desktop files? The XDG Base Directory Specification (link) says:
The order of base directories denotes their importance; the first directory listed is the most important. When the same information is defined in multiple places the information defined relative to the more important base directory takes precedent. The base directory defined by
$XDG_DATA_HOME
is considered more important than any of the base directories defined by$XDG_DATA_DIRS
.
(My $XDG_DATA_DIRS
is /home/nyanpasu64/.local/share/flatpak/exports/share:/var/lib/flatpak/exports/share:/usr/local/share:/usr/share
.)
A specification that refers to
$XDG_DATA_DIRS
or$XDG_CONFIG_DIRS
should define what the behaviour must be when a file is located under multiple base directories. It could, for example, define that only the file under the most important base directory should be used or, as another example, it could define rules for merging the information from the different files.
https://specifications.freedesktop.org/menu-spec/latest/ar01s02.html
$XDG_DATA_DIRS
/applications/This directory contains a .desktop file for each possible menu item. Each directory in the
$XDG_DATA_DIRS
search path should be used (i.e. desktop entries are collected from all of them, not just the first one that exists). When two desktop entries have the same name, the one appearing earlier in the path is used.
According to this spec, Docklike sorting the directory list is wrong. (I'm not sure how KDE or GNOME follow the spec.) I'm not sure how to order a directory and its subdirectories' .desktop files, or different .desktop files in the same directory. Hopefully it doesn't matter if we don't match other apps.
KDE mistakenly maps Flatpak Audacity to system Audacity's .desktop file (rather than the other way around). I think this is because even though /var/lib/flatpak/exports/share
comes before /usr/share/applications
in $XDG_DATA_DIRS
, the system Audacity is named audacity.desktop
, which matches WM_CLASS=Audacity
better than Flatpak Audacity, which is called org.audacityteam.Audacity.desktop
with no StartupWMClass
key.
The
<DefaultAppDirs>
element in a menu file indicates that this default list of desktop entry locations should be scanned at that point. If a menu file does not contain<DefaultAppDirs>
, then these locations are not scanned.
Amazing... now files in /etc/xdg/menus
can declare extra paths for .desktop files in <DefaultAppDirs>
lists?! (Thankfully, all the files on my system have empty <DefaultAppDirs/>
tags. I don't know if non-empty <DefaultAppDirs>
is actually present in the wild.)