Qt links against GTK to be able to use native GTK file chooser
in GTK-oriented DEs. However, GTK expects a specific environment,
which means the application needs to be wrapped to prevent crashes
when file chooser is opened in some environments.
This patch bypasses the need for wrapping Qt applications with GTK-related
environment since the file chooser dialogue will now come from a separate
process (instantiated by the XDG desktop portal via D-Bus).
In the future, we could remove the GTK dependency from Qt to fix the crashes
on non-{GNOME,Pantheon} environments. Then, users would be able to choose
between non-native Qt dialogue or native one facilitated by XDG portals
(e.g. through setting `QT_QPA_PLATFORMTHEME` to either `qgnomeplatform`,
or `xdgdesktopportal`).
One disadvantage is adding a Qt dependency to GNOME, even for people
who might not use any Qt apps. But they can easily just add `qt5.enable = false;`
to their NixOS configuration.
The configuration is also presumably less battle tested than plain Qt
with its first-party GTK integration. But it is backed by Fedora
and used by Manjaro GNOME so it cannot be that bad.
Lastly, I worry about ABI compatibility of the platform modules
with apps installed from different Nixpkgs revision.
The way `(lib.formats.yaml {}).generate` generates YAML is compliant
because on YAML 1.2 spec JSON is a subset of YAML but it bugs people's
minds and can lead to problems with software that is not compatible with
YAML 1.2.
This commit also changes the test of the generation function. Data
validation/typing remains the same.
See #133802.
Signed-off-by: lucasew <lucas59356@gmail.com>
Recommend to use services.xserver.dpi option instead. Mention in the
documentation that it's a sledgehammer approach and monitor settings should be
used instead.
Also don't set DPI in fontconfig settings; fontconfig should use Xft settings
by default so let's not override one value in multiple places. For example,
user now can set DPI via ~/.Xresources properly.
The problem behind this is that the hardened patchset[1]. Quite recently
this led to a weird problem when Linux 5.12 was dropped (and thus had to
be removed from `nixpkgs`), there were no patches for 5.13, so
`linuxPackages_hardened_latest` had to be downgraded to 5.10 as base[2]
which may be rather unintuitive and unexpected.
To avoid these kind of "silent downgrades" in the future, it makes sense
to drop the attribute entirely. If somebody wants to use a hardened
kernel, it's better to explicitly pin it using the newly introduced
versioned attributes, e.g. `linuxPackages_4_14_hardened`.
[1] https://github.com/anthraxx/linux-hardened/
[2] https://github.com/NixOS/nixpkgs/pull/133587
