I do not know which product/component to report this on, as this is a request to KDE/plasma in general, so I tried to guess the most generic one. **problem definition** Within every modern system it's quite common that new ui elements (like every kind of popups, new windows, etc.) instantaneously recognize user input, despite the fact that a normal human user cannot react on that new ui element with intent within the first 100-500 ms (I'd even say within the first second...). I'm pretty sure everyone already had some happening in the past where he wanted to click on some ui element and some other ui element (maybe even a completely different user application) pops up right under the mouse pointer some microseconds before the click happens and the wrong ui element gets the "click" event. Unintentionally. Because no one is able to react within microseconds (or even a bunch of milliseconds or even a whole second). **proposed solution** I'd like to have a central configure option which "delays" any user input to new ui elements for some sane amount of time after its creation. With a sane default of maybe some hundreds of milliseconds - where this kind of "sane" default is indeed open for discussion. **additional question** I don't know if this can be implemented in the compositor or some other component or even some toolkit below or even if I'm completely wrong here. I just want to point on this topic. So, please: As this is a quite common problem probably every fairly experienced user already suffered from but it's still not implemented by any system or ui toolkit (at least not that I know of, no gtk/gnome, no kde/qt, no MS Windows, no macOS/iOS... not even a single one) I'm asking myself what's the reason against implementing some countermeasure? If there are good reasons for having user input instantaneously available to some freshly created element, there could be some option for the author(dev) to manually override such a system default or even some project/compiler option for some build default. Maybe even some gui type elements are preferred to be on the one or other side. But I'm sill wondering why there seems to be currently no single solution in any of the modern systems. I simply do not understand this. Real world example: Quite recently I wanted to unlock my phone to look for something. The Moment I tried to unlock the phone there was an incoming call and instead of unlocking the phone I unintentionally canceled the incoming call. Does my mobile phone really thinks anyone wants to decline an incoming phone call roughly 1 millisecond after it asked for? With intent? I don't think so...
In fact, after you get familiar with a system, it is indeed possible to interact with it basically at the speed of thought bounded only by the system's own speed. So I'm afraid your proposal won't be suitable It sounds like the issue you're experiencing that led you to propose this is that of "focus stealing"--when a new window opens on top of what you were interacting with and steals your focus. KWin already has a fairly robust system of focus stealing prevention, with multiple levels that are choosable by the user. It works better on X11 than it does on Wayland, but any issues there are simply bugs that need to be fixed. I'd recommend playing with the options there and seeing if any of them meet your needs.
Thanks for your answer. no, focus stealing is not the topic here. Btw. I know there are means to prevent focus stealing, but I wouldn't call it "robust" on any of the current systems. Not at all. Focus stealing is still omnipresent on every system, likewise on KWin. For example I have some subpar user experiences with autofs auto mounting nfs storage, which pops up some message on kde/plasma which does steal the terminal focus here, for me. Having said that, that's not my point here with this feature request. Not at all. I didn't describe focus stealing here, even if this is also a topic where KWin could be improved. The named windows or pop ups here do not have to steal steal focus. They simply just appear (maybe without any input focus at all) but they get the focus "by intent" as the user activates it via some mouse click "by intent" within just a few nanoseconds(!) after their appearance. The typical user may have planned to hit some other window, at the place where the new window or popup appears. But like you said, clicking the new window is "by intent", even within just a few nanoseconds after their appearance, because - like you said - "after you get familiar with a system, it is indeed possible to interact with it basically at the speed of thought" - and the computer thinks in nanoseconds, not hundreds of milliseconds like a typical human does. So, if experienced KWin users also do think in nanoseconds, then I am definitely not an experienced KWin user. YMMV Yet, if the status quo is ok for the devs, then that's fine! Indeed, I don't think this will change any time soon. I don't think any of the alternate desktops will find a solution here before any of the big players like Apple or Microsoft will do so. It will come as a plagiarism, at the earliest, if at all, as most of the usability improvements do.