Created attachment 75151 [details] Screenshot with the bug Whenever I change any setting in KWin kcm and kwin reloads all the plugins, it lists all plugins as "could not be loaded", but all plugins are actually loaded and working. Not sure if related, but I noticed this behavior after installing nvidia 304.64 driver. Attached is a screenshot of the kcm and also output of "qdbus ... supportInformation" Can be reproduced everytime.
Created attachment 75152 [details] qdbus ... supportInformation output
Does kwin run under org.kde.kwin or some org.kde.kwin-<pid> when this happens?
After logging out and back in, I have both of them present.
Do you also have two kwin instances then? In that case, you either - run a multihead (not multiscreen, but two X11 servers for one user) system - run a second KDE session - git a kwin zombie process (which will likely consume a lot of CPU for it didn't terminate) for the first two cases you can hook into the "multihead does not work" bug [1] (and start fixing things if you want ;-) in the latter case, please check which is the zombie process and gdb attach to it, to check where it's hanging around instead of terminating. Then share that information and just SIGKILL (-9) it. [1] https://bugs.kde.org/show_bug.cgi?id=256242 [2] gdb --pid <broken kwin pid here> 2>&1 | tee ~/kwin.gdb in gdb: bt [enter, enter, ...] detach quit info is logged in ~/kwin.gdb (surprise)
> Do you also have two kwin instances then? No, just one. I have two screens using xrandr (not multihead) and I shouldn't be running two KDE sessions (by that I mean I just logged in after booting, nothing special..).
Ok, and when there are both instances, does the communication with the dialog work? (Smells like a pure issue of the KUniqueApplication "QDBusConnection: session D-Bus connection created before QCoreApplication" mumbo-jumbo failing to correctly register the service then.) a) Would you know how to sniff dbus using eg. wireshark? b) random guess: whenit does not work, do "qdbus | grep kwin" - how many services of "org.kde.kwin.Compositing" and "org.kde.kwin-*[0-9]*" are registered then? (my guts say that we'll have no "org.kde.kwin", one "org.kde.kwin-123456" and esp. only one "org.kde.kwin.Compositing" service then - in which case we could use the more reliably registered *.Compositing one)
> whenit does not work, do "qdbus | grep kwin" - how many > services of "org.kde.kwin.Compositing" none, because it's 4.9, which brings me to the question whether it can be reproduced in 4.10. The communication with KWin seems to work in general, the question is what is going wrong and whether that could still happen in master given the refactoring of the Compositor.
> Ok, and when there are both instances, does the communication with the dialog work? I'm not sure what communication you have in mind, the dialog works and responds ok as far as I can tell. > a) Would you know how to sniff dbus using eg. wireshark? I can use dbus-monitor or even bustle-dbus-monitor if that helps. > b) random guess: whenit does not work, do "qdbus | grep kwin"... As Martin pointed out, no .Compositing. Here's the output anyway: $ qdbus | grep kwin org.kde.kwin org.kde.kwin-8264 org.kde.kwin.Screenshot org.kde.kwin.Scripting
Created attachment 75164 [details] dbus service blocker Attached is a small program that does nothing but register a dbus service and then wait forever. If one kills kwin, runs the blocker, runs kwin and kills the blocker one will get the behavior described in the OP. If one does not kill the blocker, the dialog will just timeout on every dbus call. So the only important thing to check in this regard is whether org.kde.kwin is registered when this message shows up.
PS: the blocker takes one argument being the service to block ("org.kde.kwin")
Playing commit hook commit 59d1104d5e9a9bebf7b2207888c964b4becc2e78 Author: Thomas Lübking <thomas.luebking@gmail.com> Date: Sun Dec 30 00:15:30 2012 +0100 fix dbus service registration/invocation REVIEW: 108016