Bug 343519

@Thomas: what do you think about it? I think the old behavior (close after click) was wrong and inconsistent to other UIs in the systray.

Network Manager, KMix, Battery widget, etc. they serve a different purpose where multiple interactions are involved for each of the given tasks.

Klipper widget serves a single purpose to select an item. There are no multiple interactions involved when it comes to selecting an item. You select an item and then you go back to your work. If a user invokes an action, edit, or delete an item then it makes sense to keep it open but not so much when all you want to do is select an item.

Thanks for considering it.

since starting to use kde5. this has been one of a few things that i would call "annoying usability regressions" :)
all systray widgets do not serve the same purpose, as sudhir noted - the workflows around them are different. when a user selects a clipboard entry, most likely they would like to resume whatever they were doing before, and the old behaviour of closing the klipper menu worked very well for that.

note that the new behaviour is also causing another issue - if you click the topmost entry, nothing happens. in the old klipper there was an indicator to show which entry is in the clipboard - now one can not be that sure. at first, i clicked the topmost entry a lot and wondered why nothing works :)

i would also like to use this opportunity and say a huge thank you to klipper developers. despite my beef with this change, it is one awesome application that i use daily and if a klipper dev ends up in riga, latvia, poke me - i'd love to buy you a beer :)
i even know a person who uses a different desktop environment, but still uses klipper in it.
(sorry about the offtopic part, felt a strong need to express gratitude publicly)

The typical task for Klipper is selecting an entry and them middle-clicking somewhere to paste it. Unless one wants to insert the entry at the corner of the screen where Klipper is placed, what is the problem if it stays open until one clicks?

I agree with Martin that consistency should be favored here.

I do also agree, however, that we're missing a clear indicator that an entry has been selected other than that it jumps to the top position in the list). Can we highlight the selected entry in the list?

hmm, i'd disagree with middle-clicking to paste. haven't encountered many users who use it for pasting, and there are way too many new mouses that do not even have middle click ("clicking" mousewheel changes its rate, ugh - hate that).
thus most users, me including, use keyboard shortcuts to paste - be it ctrl+v or shift+ins, and not closing klipper entry popup totally breaks this workflow. it has the focus, thus i have to click an extra time in the window i want to paste in.
normally it's just "click on the entry, hit keyboard shortcut" - now, besides the extra click, i also have to identify the application, which is a nasty break in the smooth workflow.

I haven't used Plasma 5 so I'm probably not the best to judge it, but my vote goes for closing klipper after selecting an entry.

While I agree that consistency is important, I think the principle of least surprise is important too, especially when you're changing a behaviour that is expected and maybe even part of muscular memory for many.

I'm a heavy user of klipper and I can see this being very annoying for my workflow, since I'm mostly a keyboard person.

That said, I'm also a KDE/Plasma veteran user, so an option to change the default (i.e., stay open) behavior is fine for me.

My €0.02

The keyboard usecase is an important point indeed. I must admit I never use Klipper with the keyboard because in its default configuration, selecting an entry from Klipper does not put it into the regular clipboard which is pasted with e.g. ctrl-v, but only in the one which is pasted by middle mouse button.

I'm thinking whether it may make sense to close the popup when selecting an entry with the keyboard (because it can indeed break the keyboard-based workflow) but leave it open when an entry is selected with the mouse.
I'm not sure yet, but I do agree that the keyboard-based workflow should be addressed.

i rarely use klipper with keyboard only, and i really, really want it to close when i click on an entry. please. pretty please.
i'll buy somebody a beer. or two :)

(In reply to Thomas Pfeiffer from comment #7)
> ... but leave it open when an entry is selected with the mouse.

Why ?  One has made the selection, there is _no need_ for it to be left open. Never mind "guidelines" and "consistency" - Please, let common sense prevail.

Or, looked at differently. How many people using KDE4 klipper, which does close, have said "Hey guys, this should stay open after I've made my selection" ;)

Moreover in an informal and unscientific survey [1] I conducted in the KDE Google+ community, as of writing this 70% out of 206 participants do not paste directly using a hardware button (middle-mouse-button). We should not add one more step in every Clipboard interaction.

> I'm thinking whether it may make sense to close the popup when selecting an entry with the keyboard (because it can indeed break the keyboard-based workflow) but leave it open when an entry is selected with the mouse.

How do you control the widget with keyboard? My understanding is that you have to open the widget and make selection using mouse.

You can open the widget at the cursor if you set the keyboard shortcut but this floating clipboard widget is not affected with this bug. It closes itself when a selection is made either using mouse or keyboard.

[1] https://plus.google.com/u/0/+SudhirKhanger/posts/TZfUXpNs48j

There should option like “Close menu on item select”. And, probably, another option: target, where clicked item contents should be placed (clipboard or selection).

(In reply to Sudhir Khanger from comment #10)
> How do you control the widget with keyboard? My understanding is that you
> have to open the widget and make selection using mouse.

It can be open with a keyboard shorcut.

My workflow is mainly to use the clipboard with the keyboard:
- Ctrl+Q as a shortcut to open it in the bottom-right corner of the screen
- [up]/[down] arrows to select entry
- [enter] to select or [esc] to cancel (i.e. keep the already first 
- focus is automatically back to the application I was using before Ctrl+Q
And I do this very often.

Between KDE3 and KDE4, there's already the regression that [down] must be typed one more time just to skip the first entry (but it's another issue). But now with KDE5, the klipper is unusable, in 2 different ways.

1. "builtin" klipper (i.e. clipboard selected in the "general" tab of system tray settings)

- A shortcut can be selected in the "item" tab (no regression here)
- [enter] does not even select the entry
- [esc] closes the clipboard but goes to the system tray instead of giving back the focus the previously used application

2. "external" klipper (i.e. clipboard deselected, and klipper started separately from the launcher)

- Not possible to open it with a keyboard shortcut in a fixed place of the screen (preferably bottom-right). It's possible to open it at the position of the mouse but that's annoying since I never know in advance where I'll have to look.
- [enter] and [esc] work as expected.
- Bug #93649 still there ("Separate configuration from history in Klipper's popup menu").

i'd like to stress that closing the popup when clicking on an entry is still very important.
it worked really well and intuitively in kde4, and the workflow is much more painful in kde5.

I have a laptop, which does not contain a middle click button, and I find this new behaviour very annoying indeed!

looks like this might have been fixed in bug #361629 for plasma 5.6 :)

(In reply to Julien Muchembled from comment #12)
> My workflow is mainly to use the clipboard with the keyboard:
> - Ctrl+Q as a shortcut to open it in the bottom-right corner of the screen
> - [up]/[down] arrows to select entry
> - [enter] to select or [esc] to cancel (i.e. keep the already first 
> - focus is automatically back to the application I was using before Ctrl+Q
> And I do this very often.

Me too :)

> But now with KDE5, the klipper is unusable, in 2 different ways.
> 
> 1. "builtin" klipper (i.e. clipboard selected in the "general" tab of system
> tray settings)
> 
> - A shortcut can be selected in the "item" tab (no regression here)
> - [enter] does not even select the entry

Actually, if you select an entry with [enter] it jumps to second place!

> - [esc] closes the clipboard but goes to the system tray instead of giving
> back the focus the previously used application

This one doesn't happen if you configure the systray to always show klipper, only if it's hidden. Still annoying beacause I prefer it hidden.

And I also would like to select and close with [enter], like the external klipper does.

> 2. "external" klipper (i.e. clipboard deselected, and klipper started
> separately from the launcher)
> 
> - Not possible to open it with a keyboard shortcut in a fixed place of the
> screen (preferably bottom-right). It's possible to open it at the position
> of the mouse but that's annoying since I never know in advance where I'll
> have to look.
> - [enter] and [esc] work as expected.
> - Bug #93649 still there ("Separate configuration from history in Klipper's
> popup menu").

I don't mind that bug, I even like to have those options there :)

Yep, seems to have been fixed. Closing.

It's not fixed, you still have to press [esc] to dismiss klipper once you press [enter] to select an entry, wether it's setup to hidden or always visible.

At least this happens with klipper from the systray, haven't checked with the program or the plasmoid yet.

You are right. I does close with a mouse click but doesn't with an enter key.

*** This bug has been marked as a duplicate of bug 378247 ***