If we open windows manager and desktop effects the desktop effects windows freezes Reproducible: Always Steps to Reproduce: Open a window. Right click title bar "More Actions" > "Windows Manager Settings" and leave it open Next open System Settings click in "Desktop Behavior" > "Desktop Effects" Actual Results: The System Settings windows freezes for around 30 to 60 seconds Expected Results: The System Settings windows shouldn't freeze
Sounds like a dbus timeout. Please attach the output of qdbus org.kde.KWin /KWin supportInformation If that command times out as well, there's a general problem with the session dbus socket, in doubt try just "qdbus" as well.
Created attachment 92936 [details] Output of qdbus org.kde.KWin /KWin supportInformation
No, that looks fine. What happens if you call (the config module directly, close systemsettings before) kcmshell5 kwineffects does that stall as well? Does it print something "interesting" (like a kbuildsycoca5 run)?
(In reply to Thomas Lübking from comment #3) > No, that looks fine. > > What happens if you call (the config module directly, close systemsettings > before) > > kcmshell5 kwineffects > > does that stall as well? > Does it print something "interesting" (like a kbuildsycoca5 run)? If I open "Windows Manager Settings" and then run: kcmshell5 kwineffects I get: kcmshell5 kwineffects kf5.kservice.sycoca: Trying to open ksycoca from "/home/aanm/.cache/ksycoca5" #[It froze for around 1 minute here] Constructing a KPluginInfo object from old style JSON. Please use kcoreaddons_desktop_to_json() for "/usr/lib64/qt5/plugins/kwin/effects/configs/kcm_kwin4_genericscripted.so" instead of kservice_desktop_to_json() in your CMake code.
> If I open "Windows Manager Settings" and then run Is this step somehow crucial to trigger the problem?? > Trying to open ksycoca from "/home/aanm/.cache/ksycoca5" It will be either corrupt or have a timestamp or permission issue - maybe a stale lock file a) check for /home/aanm/.cache/ksycoca5.lock (delete it in case) b) stat /home/aanm/.cache/ksycoca5 c) mv /home/aanm/.cache/ksycoca5 /home/aanm/.cache/ksycoca5.broken d) run "kbuildsycoca5 --noincremental e) stat /home/aanm/.cache/ksycoca5 f) kcmshell5 kwineffects => sycoca still locks?
I ran all the steps that you have told me. If I use "kcmshell5 kwineffects" And then open Desktop Effects windows it shows up "This configuration section is already opened in KDE Control Module" and doesn't freeze for 30-60 seconds. However if I open "Windows Manager Settings" and then try to run "Desktop Effects" I have the same problem.
Ahhhhhhh... I completely misunderstood the problem. You *intentionally* try to open the kcm twice. The sycoca message is a red herring then. This happens, but don't ask me why: KWin "Show WM settings..." effectively calls kcmshell5 --icon preferences-system-windows kwindecoration kwinactions kwinfocus kwinmoving kwinadvanced kwinrules kwincompositing kwineffects kwintabbox kwinscreenedges kwinscripts & If I do this, a subsequent kcmshell5 kwineffects blocks (just like when invoking that command from the context menu) Now here's the strange part: kcmshell5 kwindecoration kwinactions kwinfocus kwinmoving kwinadvanced kwinrules kwincompositing kwineffects kwintabbox kwinscreenedges kwinscripts & and then kcmshell5 kwineffects works as expected. KCModuleProxy will have trouble to detect the opened kcm, but I've not the least idea why. What I can say for sure is that it's NOT a kwin problem, try eg kcmshell5 --icon foo style & kcmshell5 style
(In reply to Thomas Lübking from comment #7) > Ahhhhhhh... I completely misunderstood the problem. > You *intentionally* try to open the kcm twice. > > The sycoca message is a red herring then. > > This happens, but don't ask me why: > > KWin "Show WM settings..." effectively calls > > kcmshell5 --icon preferences-system-windows kwindecoration kwinactions > kwinfocus kwinmoving kwinadvanced kwinrules kwincompositing kwineffects > kwintabbox kwinscreenedges kwinscripts & > > If I do this, a subsequent > > kcmshell5 kwineffects > > blocks (just like when invoking that command from the context menu) > > Now here's the strange part: > > kcmshell5 kwindecoration kwinactions kwinfocus kwinmoving kwinadvanced > kwinrules kwincompositing kwineffects kwintabbox kwinscreenedges kwinscripts > & > > and then > > kcmshell5 kwineffects > > works as expected. > > KCModuleProxy will have trouble to detect the opened kcm, but I've not the > least idea why. > What I can say for sure is that it's NOT a kwin problem, try eg > > kcmshell5 --icon foo style & > kcmshell5 With kcmshell5 --icon foo style & kcmshell5 only one (the first one) windows opens.
(In reply to djx from comment #8) > With > kcmshell5 --icon foo style & > kcmshell5 > only one (the first one) windows opens. Sorry, was oc. supposed to be kcmshell5 --icon foo style & kcmshell5 style This was meant as "proof" that it's not related to some specific kcm or other condition, but indeed is caused by the --icon switch to kcmshell
Yep, the second one takes more time to open (around 2/3 minutes)
Thank you for the bug report. As this report hasn't seen any changes in 5 years or more, we ask if you can please confirm that the issue still persists. If this bug is no longer persisting or relevant please change the status to resolved.