KWin for wayland uses the `.desktop` file to determine whether a process
is allowed to access some wayland services.
This would be fine if there was a stable interface to map a process to a
`.desktop` file.
Since there is no such interface, they are scanning `.desktop` files for
one where the executable path matches the resolved file "exe" from
`/proc/$PID/exe`.
This would be fine, if we didn't wrap many (most?) KDE/Plasma binaries.
Since we are wrapping binaries, the `exe` symlink points to a wrapped
binary. No `.desktop` file will match for the wrapped binary.
The solution here is to peel away at the `.${name}-wrapped` layers until
we have the intended name for the executable.
It is expected that no `.desktop` file will ever point to a wrapped
binary.
As `kinfocenter`'s implementation consists of only KCMs, which are
actually just displayed using `systemsettings5`' KCM shell, the
`kinfocenter` binary is just a symlink to `systemsettings5`.
In traditional FHS environments, having a relative symlink to the
`systemsettings5` binary within the same `bin/` directory works just
fine, whereas this is broken on NixOS where `systemsettings5` resides in
a completely different `bin/` directory of the corresponding store item.
Usually CMake's `find_package` should be able to locate the
`systemsettings5` binary, but fails for reasons unknown to do so on
NixOS - so for now fixing the symlink manually as part of the `preFixup`
phase will do the job of making `kinfocenter` work again.
This reverts commit 4b7d9dc868.
The KDE project has changed their source index pages so that the links to
package metadata files are generated by JavaScript after the page loads. As a
result, wget is no longer able to recursively fetch the package metadata
automatically.
