Welcome to a new issue of This Week in Plasma!
This was a somewhat quiet week mostly full of UI and stability improvements, perhaps because many KDE contributors are gearing up for next week’s mega-sprint in Graz! For the same reason, expect next week’s post to be short or non-existent.
The lack of click feedback on menu items was the most confusing thing on KDE for me when I started using it daily, several years ago. And since then, I kinda get used to it but in some unconsciously way, it always missed me, just like clicks weren’t as effective as they should be.
So I’m pretty relieved it’ll finally be implemented, because now that I know it’ll come very soon, it has never missed me that much!
Yes, that menu item feedback is very welcome.
Is there also a feedback when you just use one click to invoke menu and select the menu entry. I.e. click on the menu title, hold the mouse clicked, move to the menu entry and then lift up the mouse button, thereby selecting the entry. I think a feedback for this kind of menu entry selection would also be very welcome.
(macOS does both kinds of feedback since it exists. You could even configure it in the pre Mac OS X days)
macOS probably has the most unique type of menu feedback. It’s not just a simple fade or background colourisation. Not sure if I like it, but it is one of things that can be used to uniquely identify a Mac from an OS skinned like mac 
That feedback was a really good UX element.
Huh, what does macOS do?
Don’t own a Mac.
But, here’s my best explanation → you click on the menu item → that click feels as a double click (the feedback is like that, the menu highlight blinks twice)
I have a proposal and question: One of the annoying things with KDE over the years is clipboard not working correctly with external apps like Signal, Thunderbird and NON-KDE-Browsers. This is somehow often an on/off bug, I find it difficult to report. As a user, I can not know, if it is a problem of KDE or the app which causes the problem. Sometimes it is fixed fast, sometimes it takes too long. My idea: Would it be possible for KDE to automatically monitor if a clipboard operation has worked and if not, give an alert which allows to report this, with the debug info? If this is a good idea, where would I report it too?
On linux there are 2 separate clipboards - one for mouse (select to copy; middle-click to paste) and the other one. I think the problem is that those applications mix these. The most common problems that I notice are that pre-select (select all in a text field that you focused) copies into the mouse clipboard, which it clearly should not do, and that sometimes text is copied into the wrong clipboard… or both.
I’m pretty sure it’s the applications fault. Determining if something is wrong could be difficult. Maybe look for mouse copy without drag? Or if both clipboards have been pasted to at the same time?
In most cases copy & paste works without the desktop getting involved.
The operation is essentially a data transfer between the two windows as long as the “source” application is still around when the paste happens.
If the “source” has been closed, the desktop’s clipboard manager Klipper will become the new source.
If in doubt you can kill Klipper and try again.