nixos/gnome: enable platform integration for Qt#136071
Conversation
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.
- https://github.com/FedoraQt/QGnomePlatform/releases/tag/0.7.0 - https://github.com/FedoraQt/QGnomePlatform/releases/tag/0.7.1 - https://github.com/FedoraQt/QGnomePlatform/releases/tag/0.8.0
github-actions
bot
added
6.topic: GNOME
|
This pull request has been mentioned on NixOS Discourse. There might be relevant details there: |
ofborg
bot
added
11.by: package-maintainer
|
Result of 2 packages built successfully:
Result of 2 packages built successfully:
1 suggestion:
|
That's not a really good idea. Unlike GTK, Qt doesn't have its own settings DB, it relies on the system to provide values. Currently, gtk platformtheme plugin is the only out-of-the-box way to set icon theme, fonts and etc for environments without its own platformtheme plugin. Also, QGnomePlatform uses GNOME/Cinnamon gsettings while the Qt's plugin uses generic GTK methods, so qgnomeplatform is useless on e.g. MATE or Xfce. The only alternative for these envrionments is qt5ct, but it's a third-party plugin and in most cases you don't need it (you can set Qt style via QT_STYLE_OVERRIDE, all other settings via GTK configurators). Also, when using xdgdesktopportal, you can't say Qt where to get other settings (like icon theme) from. And qt5ct doesn't support xdgdesktopportal (you can set it in config, but it will be reset as soon as you change something in the configurator). It's also a surprise to me that Qt doesn't uses gtk as an always-fallback, to work properly in WM-only environments without manual configuration. Maybe I should try to submit a patch to Qt to fix this, that would be a way better UX for WM users, I know a lot of them who didn't know that Qt can use system theme before I explained how to configure it to them. |
Hmm, did not realize that. That indeed complicates the matters.
Yeah, we might try to convince QGnomePlatform to fall back to GTK settings where possible.
I wonder if an official setting key for that would be recognized: Currently, flatpak just reads GtkSettings and likely needs dconf permission:
Maybe that could be fixed in qt5ct or some other component?
Do you mean https://github.com/qt/qtbase/tree/9db7cc79a26ced4997277b5c206ca15949133240/src/plugins/platformthemes/gtk3? Does that really support GTK themes? What is the purpose of QGnomePlatform then? |
Well, gtk developers like dbus, Qt developers seem to prefer ini configs...
It's an one line patch for the configurator, but the fact qt5ct hosts on sourceforge turns submitting the patch into a quest. |
4 participants
Motivation for this change
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_PLATFORMTHEMEto eitherqgnomeplatform, orxdgdesktopportal).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.
Things done
sandbox = trueset innix.conf? (See Nix manual)QT_QPA_PLATFORMTHEME=qgnomeplatform QT_STYLE_OVERRIDE=adwaita calibrefollows the theme and file chooser uses portal.nix-shell -p nixpkgs-review --run "nixpkgs-review wip"./result/bin/)