Version: 0.9.6 (using KDE 4.4.5) OS: Linux First entry is not checked when something is copied by CTRL-C or mouse selection, even after choosing it in klipper window after copy. The undesired behavior is that I cannot use this first copy in many applications. I am using an ugly workaround that is selecting another non first entry in klipper window, and after I select the previous one. This previous is now checked and works in all applications. The application version is really 0.9.7 (not listed). Reproducible: Always Steps to Reproduce: - CTRL-C or mouse select some text - In klipper window select the first entry Actual Results: The first entry is not checked, and it should. Expected Results: First entry checked. OS: Linux (x86_64) release 2.6.32-3-amd64 Compiler: cc
I cannot reproduce this in KDE4.6.1. Is this issue fixed?
(In reply to comment #1) > I cannot reproduce this in KDE4.6.1. Is this issue fixed? Yes, thanks.
This still happens to me in KDE-4.7.2 on Mageia Linux Cauldron. It's quite annoying.
Created attachment 64339 [details] Patch to fix the problem (at least partly). This patch against the KDE/4.7 branch allows one to select the top item after it was pasted. Please apply it.
I have a spot of trouble testing it, but while I work that out: Why would you select the top spot? It should be paste-able already. Is it a way to sync. mouse selection and clipboard? Or paste after an application exists? Or something else?
(In reply to comment #5) > I have a spot of trouble testing it, but while I work that out: Why would you > select the top spot? It should be paste-able already. Well, it should. However, immediately after copying to the clipboard, there is no checkmark next to it, so there is no visual cue that it is the active selection and so I am tempted to select it again, just to mark it as such (which also doesn't work). > Is it a way to sync. > mouse selection and clipboard? Or paste after an application exists? Or > something else? It is away to check it using a checkmark. Regards, -- Shlomi Fish
Ah, the check mark is supposed to tell that it is klipper that is holding the clipboard. IMHO, it is rather redundant and could be removed entirely.
(In reply to comment #7) > Ah, the check mark is supposed to tell that it is klipper that is holding the > clipboard. IMHO, it is rather redundant and could be removed entirely. I don't think so. In some applications the copied text only gets pasted when there is the check marked. I don't know exactly how the clipboard works, but there is some wrong synchronization between the various selections. The bug is: when I select the first entry these various selections do not get synced; when I select any other it gets synced. This second behavior is the right one.
*** Bug 248516 has been marked as a duplicate of this bug. ***
*** Bug 228737 has been marked as a duplicate of this bug. ***
It still happens on Debian Wheezy (kde 4.8).
Still reproducible with plasma-workspace 5.2.0 When the first entry is from primary selection, then when I click it, it's not checked. And the clipboard content is not updated. A workaround is click the second entry to make the first second, then click the now second entry.
For plasma-5 this could be a bug with comparable symptoms (though other cause): https://bugs.kde.org/show_bug.cgi?id=329174
this is still an issue here, with openSUSE packages built from git master.
I am running Qt 5.5 and klipper is still broken. I copy text, and it makes it into Klipper, but I try and paste, and nothing will paste. I select the item from Klipper's history but there is still no checkbox next to it. I have to select something else in the history list (which will show a checkbox) *then* can select what I just copied and paste it.
@EMR_Kde Turn on option "synchronize contents of the clipboard and the selection" in klipper plasmoid settings. Then it will work as expected. By default it will paste text from top of the list with middle mouse click not with ctrl+v. Above option fixed it.
The behaviour seems to be fixed now in plasmashell 5.5.3 (KDE backports for kubuntu/wily). After choosing an entry from the klipper widget I can paste it using the middle mouse key as well as using ctrl+v, without having set the option "synchronize contents of the clipboard and the selection". (The option would be a very bad workaround as you would loose the functionality of having two clipboard buffers, the one for the mouse and the other for the keyboard.)
This is still an issue with Klipper 5.6.95 on Plasma 5.6.5 installed on Neon's developer edition. Steps to reproduce: 1. Make sure "Synchronize content" is *not* checked in Klipper configuration. 2. Select some text and copy it to the primary clipboard using CTRL+C or the "Copy" RMB menu option. The text will be the first entry in the Klipper menu, and not checked. Now "paste" as well as MMB would paste the first entry. This behavior is not Klipper related. 3. Select some other text (copying it to the "selection" clipboard). The second text will be the first entry in the Klipper menu, and not checked. Now MMB would paste the second text while CTRL+V or "Paste" RMB menu option would paste the first text. This behavior is not Klipper related. 4. Open the Klipper menu and choose the first entry (containing the second text). Expected behavior: Klipper would take ownership of the second text and copy it to the primary clipboard (and "selection" though it already contains the same text), marking it in the Klipper menu with a checkbox. Now the second text is pastable using both MMB (from the "selection" clipboard) and the "Paste" command (from the "primary" clipboard). Actual behavior: Nothing happens. Klipper does not take ownership of the text, does not copy it to "primary" and does not make it available for the "Paste" command. It is worth noting, I believe, that the main problem I have with this behavior is that it is mostly surprising because the first entry is treated differently from all other entries - where selecting any entry other than the first will cause Klipper to take ownership of the clipboard and copy the entry to both "primary" and "selection", while the selecting the first entry is simply ignored.
Git commit 37014e643cec4ee9aed54421f66c675e1bc91b70 by Luboš Luňák. Committed on 17/04/2017 at 11:13. Pushed by lunakl into branch 'master'. selecting the topmost klipper item should always set it as clipboard contents Without this, that wasn't always the case if the top item was only the mouse selection. This was presumably broken by 2e47d84772. Also explicitly check the popup item, since it's now owned by Klipper. Related: bug 348390 M +11 -0 klipper/history.cpp M +1 -0 klipper/history.h M +1 -0 klipper/klipper.cpp M +7 -0 klipper/klipperpopup.cpp M +1 -0 klipper/klipperpopup.h https://commits.kde.org/plasma-workspace/37014e643cec4ee9aed54421f66c675e1bc91b70
(In reply to Lubos Lunak from comment #19) I can confirm that things have changed for the better. I'm so relieved that this is working again. ... well mostly. I've found that konsole/yakuake does not grab the last entry from the clipboard. The second situation comes from using kde-connect; while the clipboards get properly synchronized, the mouse action still does not pick up the right entry. nonetheless, thanks a lot for the fix
Git commit f78b0869f01d255d0e17a0a246e5a9456f2bba4e by Luboš Luňák. Committed on 26/04/2017 at 09:06. Pushed by lunakl into branch 'Plasma/5.8'. selecting the topmost klipper item should always set it as clipboard contents Without this, that wasn't always the case if the top item was only the mouse selection. This was presumably broken by 2e47d84772. Also explicitly check the popup item, since it's now owned by Klipper. Related: bug 348390 M +11 -0 klipper/history.cpp M +1 -0 klipper/history.h M +1 -0 klipper/klipper.cpp M +7 -0 klipper/klipperpopup.cpp M +1 -0 klipper/klipperpopup.h https://commits.kde.org/plasma-workspace/f78b0869f01d255d0e17a0a246e5a9456f2bba4e
Git commit 921f89cb62e2fa118ba16ea87bcec0ba41751a82 by Luboš Luňák. Committed on 26/04/2017 at 09:07. Pushed by lunakl into branch 'Plasma/5.9'. selecting the topmost klipper item should always set it as clipboard contents Without this, that wasn't always the case if the top item was only the mouse selection. This was presumably broken by 2e47d84772. Also explicitly check the popup item, since it's now owned by Klipper. Related: bug 348390 M +11 -0 klipper/history.cpp M +1 -0 klipper/history.h M +1 -0 klipper/klipper.cpp M +7 -0 klipper/klipperpopup.cpp M +1 -0 klipper/klipperpopup.h https://commits.kde.org/plasma-workspace/921f89cb62e2fa118ba16ea87bcec0ba41751a82