Bug 343519 - Klipper systray widget is not closed automatically once a user has selected an item
Summary: Klipper systray widget is not closed automatically once a user has selected a...
Status: RESOLVED DUPLICATE of bug 378247
Alias: None
Product: klipper
Classification: Unmaintained
Component: plasma-widget (show other bugs)
Version: 5.2.0
Platform: Fedora RPMs Linux
: NOR normal
Target Milestone: ---
Assignee: Martin Flöser
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-01-29 12:45 UTC by Sudhir Khanger
Modified: 2021-04-01 20:07 UTC (History)
8 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sudhir Khanger 2015-01-29 12:45:30 UTC
Widget should be automatically closed after a user has selected an item. Currently, I select an item and then I have to click another window or somewhere else in order to close the widget. This is how  it works if you open a Klipper window via "Open Klipper at Mouse Position" and widget in KDE 4 also closes if you click an item.

Reproducible: Always

Steps to Reproduce:
1.Open Klipper widget in system tray
2. Click an item
3.

Actual Results:  
Klipper widget doesn't hide itself after a use has selected an item.

Expected Results:  
Klipper widget should hide itself once a user has selected an item.
Comment 1 Martin Flöser 2015-01-29 15:03:40 UTC
@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.
Comment 2 Sudhir Khanger 2015-01-29 16:36:16 UTC
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.
Comment 3 richlv 2015-12-09 10:26:05 UTC
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)
Comment 4 Thomas Pfeiffer 2015-12-13 17:33:29 UTC
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?
Comment 5 richlv 2015-12-13 18:01:13 UTC
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.
Comment 6 Ricardo J. Barberis 2015-12-15 03:09:09 UTC
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
Comment 7 Thomas Pfeiffer 2015-12-15 15:43:17 UTC
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.
Comment 8 richlv 2015-12-15 15:45:06 UTC
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 :)
Comment 9 Paul 2015-12-15 16:46:03 UTC
(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" ;)
Comment 10 Sudhir Khanger 2015-12-15 17:17:56 UTC
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
Comment 11 Sergey Stolyarov 2016-01-25 07:53:35 UTC
There should option like “Close menu on item select”. And, probably, another option: target, where clicked item contents should be placed (clipboard or selection).
Comment 12 Julien Muchembled 2016-02-24 19:27:37 UTC
(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").
Comment 13 richlv 2016-02-24 22:26:52 UTC
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.
Comment 14 Teresa e Junior 2016-06-09 15:14:07 UTC
I have a laptop, which does not contain a middle click button, and I find this new behaviour very annoying indeed!
Comment 15 richlv 2016-11-20 14:59:06 UTC
looks like this might have been fixed in bug #361629 for plasma 5.6 :)
Comment 16 Ricardo J. Barberis 2016-12-04 21:14:11 UTC
(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 :)
Comment 17 Sudhir Khanger 2016-12-05 15:38:17 UTC
Yep, seems to have been fixed. Closing.
Comment 18 Ricardo J. Barberis 2017-03-16 22:50:10 UTC
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.
Comment 19 Sudhir Khanger 2017-03-17 02:59:41 UTC
You are right. I does close with a mouse click but doesn't with an enter key.
Comment 20 Nate Graham 2021-04-01 20:07:38 UTC

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