I just installed KDE 5.5.4 (I think -- I cannot obtain the number without running a program).
Whatever version comes with openSUSE 42.1.

Anyway, when I click on the start menu, the menu appears for one monitor refresh cycle. I'm not fast enough to click anything. I can click on the background and select "run command", but the run command dialog does not last any longer than the menu does. This is the second time. The first time, I didn't have any programs on the desk top. Consequently, I simply deleted everything in my home directory and was back to "normal". This time, I have a console and Firefox, so I can send this email. There should be no possible way to have this behavior, ever. So that is a bug that must be reported. Meanwhile, I need to know the cause so that I can use more than just the browser and the console. I suppose I can learn the commands behind the icons and fire them off from the console, but that is a big nuisance and very tacky.

I do think I might have the cause, but if I am right then I still need to undo the damage and somebody needs to undo some excessive cleverness straight away. I did three things just before this failure:

1) increased my desktops to 12
2) added Ctl-F8 through Ctl-F12 shortcuts
3) Moved the focus method to "focus follows mouse"

then exited the configure desktop. My theory is that the start menu and the run command dialog get instantly de-selected because the mouse is not over them. If that is true, then that would be a remarkably poor choice. Mouse-over-root-window should not choose the root window over a popped up dialog and mouse-over-panel should not choose the panel over the menu, if these are, indeed, the causes of the problems. It would mean that "focus follows mouse" was destroyed as a usable policy but left as an option for those of us who really, really, really like to use it.

being able to run programs again requires changing something in ~/.config.
I do not know what, yet, because searching for "mouse" and "policy" in the "plasma*" files yielded no results.
At least, I am _guessing_ that the mouse policy issue is causing the problem and configured there.
I'd like to know for sure ....

OK, I moved the slider one past where I wanted it. The result is a configuration where the desktop does not work. Just like it says. However, it is so completely broken that it should not even be allowed. If it is allowed, it ought to have a prompt, "Do you know what you are doing? Do you know that this setting makes the desktop non-functional?" I did not realize I'd moved the slider too far.

Well, I take it back. With the setting set to the middle of the slider where it doesn't say, "does not work", I still _sometimes_ get the anomalous behavior. I was getting that behavior and came back here only to find that now it is working again -- without having made any configuration changes. The intermediate thing I did was try to report a seg-fault/crash:

Application: Plasma (plasmashell), signal: Segmentation fault
Using host libthread_db library "/lib64/libthread_db.so.1".
[Current thread is 1 (Thread 0x7f3d64c547c0 (LWP 9328))]

but despite going through the installation of the debug symbols, "finish" never lights up and I am told:

This crash information is not useful enough, do you want to try to improve it? You will need to install some debugging packages.

and I am asked if I want to install debug symbols (again). Useless.

in ~/.config remove/rename kwinrc

The cause is that all plasma popups are now in fact managed windows which close themselves as soon as they loose the focus what of course makes them virtually unusable with the focus-under-mouse strategies and rather wonky (we had that with the early plasmoid list) with focus follows mouse.

Bright new QtQuick world; get used the click-to-focus.

luebking wrote:The cause is that all plasma popups are now in fact managed windows which close themselves as soon as they loose the focus what of course makes them virtually unusable with the focus-under-mouse strategies and rather wonky (we had that with the early plasmoid list) with focus follows mouse.

Bright new QtQuick world; get used the click-to-focus.

It is, unfortunately, impossible to "get used [to] click-to-focus". The problem being that the click gets passed through to the application and the application responds to the click. Oops. So I have it set to "Focus *Follows* Mouse", except that (apparently) there was a glitch and plasma slipped into "Focus Under Mouse" momentarily. It went into and out of that state without my changing the system settings. I do not believe that that is the expected behavior and is a bug. If I see it again, I'll file one, but I cannot reproduce it at the moment.

Suggestion for plasma developers: either remove all (two) "focus under mouse" selections or force the slightly clumsy to verify that that is what they really want.

The click passing is independent of the focus model, see the actions tab in "kcmshell5 kwinoptions" - don't use activate, raise & pass click, but just activate & raise (or only activate)

I'd suggest to have the QtQuick pseudo-popups fixed (because otherwise one would have to remove everything but click to focus, focus follows mouse depends on delay settings and the focus stealing preventions policies must be removed as well)

luebking wrote:The click passing is independent of the focus model, see the actions tab in "kcmshell5 kwinoptions" - don't use activate, raise & pass click, but just activate & raise (or only activate)

I was aware of that. It just slows my work flow to have to click. I switch from window to window a lot. A real lot. I'd be constantly clicking. Bzzt.

I'd suggest to have the QtQuick pseudo-popups fixed (because otherwise one would have to remove everything but click to focus, focus follows mouse depends on delay settings and the focus stealing preventions policies must be removed as well)

Indeed. I have stealing prevention set to extreme. "smart placement" used to put the popups on open territory, but they seem to show up tucked under stuff now. Ick.