You are not logged in.
I use the following QT apps:
- kdenlive
- vlc
- audacity
All three honor QT_SCALE_FACTOR=1.75 (I have put it in .xprofile as well as in /etc/environment) if I install it normally with yay -S <package>
But if I download the app image and execute it, it doesn't seem to read the environment variable.
I have tried giving the environment variable for just that command as well, didn't work either (QT_SCALE_FACTOR=1.75 ./vlc.appimage)
The environment variable is definitely there, because if I open a new shell and echo it it shows up.
How to fix?
[Edit]
I tried passing a non-QT environment variable i.e VLC_VERBOSE, and that worked properly.. so it's just the qt library inside the app image that is not reading this environment variable.
Last edited by porridgewithraisins (2023-12-12 05:37:58)
Offline
An appimage uses it's own bundled toolkit, not the system's qt libraries. That's the point of an appimage. If that's not what you want, don't use is and use real packages instead.
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
I don't mind it using its own bundled QT libraries.. but do you know how to set environment variables for said bundled QT library?
Offline
Try
flatpak override --env=VAR=VALUE $applicationReplace VAR, VALUE & $application with the desired strings. Omitting $application will apply the variable to all flatpak applications.
See also flatpak-override(1).
Jin, Jîyan, Azadî
Offline
I am using appimages, but thanks, i'll see if there's some magic option required to set environment variables for appimages. Doesn't look that way as I was able to set VLC_VERBOSE. It seems only QT env vars are not working.
Offline
I am using appimages,
Oh dear, sorry about that. It's very early here ![]()
Sorry for the noise.
Note to self: don't post before tea.
EDIT: does this help?
https://docs.appimage.org/packaging-gui … ables.html
Last edited by Head_on_a_Stick (2023-12-12 06:11:49)
Jin, Jîyan, Azadî
Offline
That seems to be about appimage-specific environment variables such as ARGV0
, I don't think that covers external environment variables.
Perhaps it is inherent in QT app-images that they don't honor QT_* environment variables..
Offline
An appimage uses it's own bundled toolkit, not the system's qt libraries.
Did you inspect the environment of the process on whether the QT_SCALE_FACTOR shows up there?
Because if it does, the problem is not to impact the environment but that the bundled Qt version gives two fucks about it.
tr '\0' '\n' < /proc/$(pidof containersareastupididea)/environOffline
Totally forgot I could do that!
$ cat /proc/$(pgrep VLC)/environ | tr '\0' '\n' | grep QT
QT_SCALE_FACTOR=1.75So I guess like you said, appimage bundled QT libraries don't care about environment variables.. that sucks.
Do you know where this can be reported? Is it within the purview of the appimage bundling software, QT itself, or the specific application?
Last edited by porridgewithraisins (2023-12-12 08:00:43)
Offline
The appimage.
Wtf do you use an appimage of https://archlinux.org/packages/extra/x86_64/vlc/ ?
Masochism?
Offline
I was trying to reproduce it for a popular app to see where the issue was.
Offline
This is what I was getting at. There is no magic to environment variables giving them power to override anything - they're conceptually a bit like rc/config files: if the relevant software doesn't read / check these, they can have no impact. The pacman-installed QT libraries are built in such a way that they read / honor variables like QT_SCALE_FACTOR. There is no reason to assume the bundled libraries in an appimage will. In fact, app images may use slimmed down versions of libraries that provide the bare minimum of what the appimage creator feels is necessary.
If the appimage QT implementation lacks any features you take for granted in the distro-provided QT packages, there's really nothing we can do about that. And again, that's really the point of an appimage: you get what the appimage author thinks is best, and that's it.
And now we learn this is really an X-Y question as the problem is with yet another appimage. That other appimage has yet another qt implementation of it's own. There's also no reason to expect this one to be similar to the system qt - but more relevantly here, there's no reason to expect the other application's qt to be similar to the qt implementation in the vlc appimage.
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
There's also a good chance that the appimage just uses a statically linked Qt which is implicitly severely constrained.
Either way and going with what Trilby alluded to, we might want to focus on the target application and why you're resorting to an appimage - and which one specifically.
Offline