About 50% of the time it happens that the "sliding popup" effect is not fully working during the whole user-session. The dice to decide for state "broken" or "not broken" is tossed at login-time. Reactivating the effect at kwin-settings doesn't change anything. So what is the "broken state": all plasma-applets excluding the system-tray expansion are not sliding anymore (including the "device manager", the networkmanagement-applet, notifications, print-jobs, ...) I'll attach the .xsession-errors file which was generated in a "broken state" session. Reproducible: Always
Created attachment 80410 [details] xsession errors
This kinda sounds like bug #179042 but that should be fixed by 4.10.4 - does "work/works not" correlate with the appearance of panels etc?
(In reply to comment #2) > does "work/works not" correlate with the appearance of panels etc? What exactly do you mean? The appearance of my panels is independend of the "work/works not" state; there is no difference. There is one thing though: I'm using the icon-only-task-manager (which seems to be a little broken when using tabbed windows; but I didn't report anything yet) in combination with the "Present Windows Effect" (as "Group click action"). The conjecture is: * "Not Broken state": clicking on a "group icon" the Present Window Effect is used [this only works if windows are not tabbed, otherwise nothing happens; but as I said this should be another bug.] * "Broken state": clicking on a "group icon": Despite the fact that "present window effect" is set in the options, the behaviour of "show popup menu" is used. Btw: I just noticed that disabling/enabling desktop effects brought sliding as well as the icon-only-tm-"present window effect" back.
This suggests a misdetection of the compositing state and/or the effect availability in plasma-desktop what was supposed to be fixed with bug #179042 - and apparently in a way is (since toggling compositing seems to retrigger the detection and fix the state. > What exactly do you mean? The appearance of my panels is independend of the "work/works not" state; there is no difference. The panels use different themes depending on whether compositing is active or not resp. blur is available or not. So if plasma-desktop (in general) had a wrong idea about the compositing being active, that would be broken as well. Attaching plasma-devs: this might be a simple race condition in that the effect support properties are tested (before announced) and then the property gets watched (after being announced, missing the state change)
(In reply to comment #4) > The panels use different themes depending on whether compositing is active > or not resp. blur is available or not. I will test this as soon as it happens again. > So if plasma-desktop (in general) had > a wrong idea about the compositing being active, that would be broken as > well. This suggests that the "wrong idea" is the idea of compositing being deactivated? You may find it interested then that the "Scale in" effect is always working (it does the "scale in" when the "sliding popup" doesn't work btw). And as mentioned: the system-tray-icon-expansion is always "sliding" (even in the "broken" case).
(In reply to comment #5) > You may find it interested then that the "Scale in" effect is always working No. KWin knows that the compositor is active bacause it runs it ;-P > (it does the "scale in" when the "sliding popup" doesn't work btw). And as yes, because the popup does not request to be slided in. > mentioned: the system-tray-icon-expansion is always "sliding" (even in the > "broken" case). I don't know but assume that the various plasmoids or containments track the presence of announced features all themselves. Re-assigning to plasma to check on guess in comment #4
Hello! This bug report was filed for KDE Plasma 4, which reached end-of-support status in August 2015. KDE Plasma 5's desktop shell has been almost completely rewritten for better performance and usability, so it is likely that this bug is already resolved in Plasma 5. Accordingly, we hope you understand why we must close this bug report. If the issue described here is still present in KDE Plasma 5.12 or later, please feel free to open a new ticket in the "plasmashell" product after reading https://community.kde.org/Get_Involved/Bug_Reporting If you would like to get involved in KDE's bug triaging effort so that future mass bug closes like this are less likely, please read https://community.kde.org/Get_Involved#Bug_Triaging Thanks for your understanding! Nate Graham