Created attachment 1618064 [details]
Description of problem:
Note: I couldn't find which component to file this bug under so I picked dolphin because this bug affects dolphin (as well as other qt applications)
When launching a KDE / QT application such as Dolphin or Spectacle from an application that utilizes qdbus, the qt application will lose the user selected widget style (usually breeze) and use the ugly default qt theme. For example, in the dropbox flatpak from flathub, if I open dropbox folder from the tray icon, dolphin launches without theming and looks ugly. Or if I enabled the file / folder search in krunner, and open a folder that exists on my system in dolphin with krunner, it loses the theme. If I launch Dolphin (only the application, just launching from the .desktop file) in krunner the theme works. This issue can be quickly reproduced by launching Spectacle in the terminal normally (theme works), then launching it with this command:
qdbus org.kde.Spectacle / StartAgent
in which spectacle launches without the theme (ugly)
Version-Release number of selected component (if applicable):
not sure what component provides qdbus
Steps to Reproduce:
1. launch spectacle in terminal normally (theme works)
2. close spectacle
3. launch spectacle with this command: qdbus org.kde.Spectacle / StartAgent
4. notice theme looks ugly
When launching a qt application from qdbus or from flatpak it loses the theme.
The theme should work when launching qt applications in this way.
Attached is an screenshot of what Dolphin looks like on my system when launching from dropbox flatpak or selecting a folder in krunner. (dolphin-ugly.png)
Also attached is what dolphin looks like when launching normally. (dolphin-normal.png)
Created attachment 1618065 [details]
what dolphin is supposed to look like
Does anyone pay attention to these bug reports?
Yes, people pay attention. Personally, I've just had no time to look deeply yet, even less so to add acknowledgements for every incoming bug report. Patience grasshopper.
That said, this almost certainly isn't a dolphin issue (ie, problem lies elsewhere). One possibility: dbus-activated applications may not inherit (all? any?) user environment variables
FEDORA-2019-1f174ad525 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2019-1f174ad525
baloo-widgets-19.08.2-1.fc31, dolphin-19.08.2-2.fc31, dolphin-plugins-19.08.2-1.fc31, kate-19.08.2-1.fc31, kdialog-19.08.2-1.fc31, keditbookmarks-19.08.2-1.fc31, kfind-19.08.2-1.fc31, khelpcenter-19.08.2-1.fc31, konqueror-19.08.2-1.fc31, konsole5-19.08.2-1.fc31, yakuake-19.08.2-1.fc31 has been pushed to the Fedora 31 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-1f174ad525
Hi, thanks for taking a look at this. However, even with that dolphin update, the issue still occurs with dolphin. (And other qt applications, but that would require some other update)
baloo-widgets-19.08.2-1.fc31, dolphin-19.08.2-2.fc31, dolphin-plugins-19.08.2-1.fc31, kate-19.08.2-1.fc31, kdialog-19.08.2-1.fc31, keditbookmarks-19.08.2-1.fc31, kfind-19.08.2-1.fc31, khelpcenter-19.08.2-1.fc31, konqueror-19.08.2-1.fc31, konsole5-19.08.2-1.fc31, yakuake-19.08.2-1.fc31 has been pushed to the Fedora 31 stable repository. If problems still persist, please make note of it in this bug report.
This is not fixed.
Related bug 1749362 ?
Yes. Same bug.
The update above should fix dolphin, as it is no longer dbus-activated on f31+ (it is autostarted with: dolphin --daemon on session start instead).
*** Bug 1749362 has been marked as a duplicate of this bug. ***
It doesn't fix it, as dolphin can still be launched with dbus (for example - from a flatpak)
Interesting, the mechanism is different now.
dolphin running as a background daemon listening on that dbus interface (as part of your user session) now launches dolphin, instead of dbus itself. Means that the dolphin daemon isn't inheriting your session environment properly either?
Odd, I recall it working for me in my own testing at the time I made the update (I don't have a f31 box handy currently to retest).
I am experiencing this with KeePassXC on Fedora 31. When I launch it via terminal it works as expected but when launched from KRunner then the theme gets messed up.
Don't know if it's related or not but I have following error when running `dbus-update-activation-environment --all --systemd` from the console:
dbus-update-activation-environment: warning: error sending to systemd: org.freedesktop.DBus.Error.InvalidArgs: Invalid environment assignments
Also I see such errors in the ~/.xsession-errors after every login to KDE.
Issue is gone after I uninstall package Lmod, it exports some env variables with new lines and tab characters (BASH_FUNC_ml%% and some other).
Command `systemctl --user import-environment` will fail to import those variables.
Removal of Lmod package fixed issue for me with Spectacle.
Removing Lmod solved the issue for me. I had to do it via "sudo rpm -e --nodeps Lmod" because some packages I use (like Kdenlive) depended on it.
Can Lmod be removed safely without it causing harm to other apps like Kdenlive?
I haven't noticed any issues in my minimal testing, and I don't think it's needed though I'm not sure what Lmod does.
I also removed Lmod, and got system themes back in Spectacle. For many users, it seems to be a dependency (in my case, the Nomacs image viewer). It seems that the reason we all have this same bug is OpenCV, which both Nomacs and Kdenlive are using.
I'm a rookie in these parts though, so I'll leave it to The Powers That Be to decide whether a bug should be filed against Lmod instead dolphin.
I am also seeing this and this dependency seems to be required by e.g. digikam.
Want to add that this is affecting Spectacle for me on KDE Plasma with Fedora 31 updated to the latest packages.
I had this annoying problem also with Spectacle. Not only losing the system theme but also the 2x scaling which made it impossible to use on my HiDPI screen.
The comment #17 above about importing user environment gave me some tips on solving this issue.
Here are my steps:
run 'systemctl --user import-environment' from the command line.
If you see any errors, then your environment failed to get passed into systemd user instance, and therefore not passed into dbus activated programs.
The next step would be to pin-point where the error occurs during the import. For this I'm afraid there's no approach other than trial and error. Start with the most basic .bashrc, or .zshrc, etc. Then invoke a login shell (normally with the -l argument to the shell), and rerun the import command above. You may need to disable the scripts under /etc/profile.d as well.
If #25 is right - it'd be nice if we could have some confirmation or a script we could run to check this.
Cause of this bug is simple - systemd don't import ALL enviroment variables if any variable name is not POSIX compilant
(it must conform to the regex [0-9A-Z_], see: https://github.com/systemd/systemd/blob/a859abf062cef1511e4879c4ee39c6036ebeaec8/src/basic/env-util.c#L19).
You can test it with this command: `env %=1 systemctl --user import-environment`, it will fail.
Now there is 2 known packages exporting those variables: environment-modules and Lmod.
Solution is simple - skip ONLY invalid variables while importing others.
I've created bug in the systemd, but still without answer - https://github.com/systemd/systemd/issues/14878.
Created attachment 1675998 [details]
If the mountain will not come to Muhammad...
There is a patch to fix this issue for KDE.
It must be applied to the plasma-workspace.
Someone - please test it, it should help, but anyway some testing required.
(In reply to Yaroslav Sidlovsky from comment #28)
> Created attachment 1675998 [details]
> If the mountain will not come to Muhammad...
> There is a patch to fix this issue for KDE.
> It must be applied to the plasma-workspace.
> Someone - please test it, it should help, but anyway some testing required.
I tested the patch because you uploaded it to your copr repo and it seems to work fine.
imported patch, only for f32+ currently.
Will likely be working on plasma-5.18 update for f31 soon that will include this fix too
Created attachment 1676095 [details]
I've just made more complex and more correct (as I think) patch that modifies environment only for process "dbus-update-activation-environment".
After applying this patch:
$ LANG=C journalctl -b 0 -g 'environment variable removed'
-- Logs begin at Fri 2020-04-03 11:15:20 MSK, end at Fri 2020-04-03 20:51:11 MSK. --
Apr 03 20:44:31 rapidus startplasma-x11: program: "dbus-update-activation-environment" environment variable removed: "BASH_FUNC_ml%%"
Apr 03 20:44:31 rapidus startplasma-x11: program: "dbus-update-activation-environment" environment variable removed: "BASH_FUNC_module%%"
Apr 03 20:44:31 rapidus startplasma-x11: program: "dbus-update-activation-environment" environment variable removed: "LMOD_sys"
Created attachment 1676096 [details]
Thanks, triaging to plasma-workspace component
Applied latest patch submission to plasma-workspace :
* Thu Apr 09 2020 Rex Dieter <firstname.lastname@example.org> - 22.214.171.124-2
- update patch "Qt applications lose system theme if launched via dbus activation" (#1754395)
As of most recent updates it appears to be fixed now. At least I can launch KDE programs from the launcher and they're coming up with the right theme instead of a light theme.