Version: v0.9.7 (using 4.3.86 (KDE 4.3.86 (KDE 4.4 >= 20091231)), Gentoo) Compiler: x86_64-pc-linux-gnu-gcc OS: Linux (x86_64) release 2.6.31-gentoo-r6 This is trunk as of 03-01-2009 (from Gentoo packages), Qt 4.6.0 Enabled Klipper settings as follows (only those): - save clipboard on exit - prevent empty clipboard - remove whitespace when executing actions - ignore images - ignore selection also clipboard actions disabled. Selecting some text in clipboard-aware area (for instance in kate) and invoking CTRL+C makes selected contents copied to clipboard. But.. very often it's not available for pasting (that's it). Looking at clipboard items list, recently copied item is clearly there, it's even possible to edit it using 'Edit contents' but one cannot paste it (that's separate bug reported already IIRC). And now this bug - one cannot even click on this recently added item to make it 'selected' or 'active' thus ready for pasting - such action has no effect. It's need to first select some other clipboard item and then select the one we wanted in first place. Btw, no Java applications (like Netbeans or Eclipse) or other clipboard 'stealing' utilities running. Reproducible quite often and a bit frustrating - usually when opening some document only to copy some text (either keyboard accelerator or from main menu or from context menu - all ways are affected), closing it only to realize either nothing has been copied to clipboard or item in clipboard but cannot paste unless workaround described above applied. plz2fix :)
I have also faced this issue many times. Sometimes I copy text or link from evolution mail client but when I try to paste, it does nothing. I have to select from klipper again. Qt: 4.6.1 KDE Development Platform: 4.3.86 (KDE 4.3.86 (KDE 4.4 >= 20091231)) "release 6" Klipper: v0.9.7
Selecting the top should work again, real soon. The fix is here locally.
I see some improvements in 4.4 branch, recently copied item can be activated now indeed (which saves a lot of frustration :). Still the main problem remains - usually one cannot paste it unless selected explicitly (this happens especially when trying to copy/paste between different applications, like when opening some file, copying contents, closing file and trying to paste somewhere else - as written in bug description). I suppose it may be related to some "ignore selection" related code but don't quote me on that.
Ignore selection is neither here nor there. The crux of the matter is Qt converting the asynchronius clipboard events to sync. events, and some application being very slow to respond. Still, I need an actual steps-to-reproduce to fix it at any speed.
I also experience this problem often. Currently my KDE's version is 4.3.95. Configuration of my Klipper: [$Version] update_info=klipper-kconfigxt.upd:KlipperNoSpacesInKeyNames [General] IgnoreSelection=true MaxClipItems=20 Number of Actions=0 PopupAtMousePosition=true Version=v0.9.7
Here's what I see, first what works: - Open a text file in e.g. Kwrite and highlight some text - go to another application, in this example Dolphin's location bar, middle click, the text is pasted the same when copying rather than just selecting/highlighting what doesn't work: - Open a text file in e.g. Kwrite and highlight some text, then close kwrite - go to another application, in this example Dolphin's location bar, middle click, nothing happens the same with copying rather than just selecting/highlighting. So it seems to me that the "prevent empty clipboard" options isn't working correctly, i.e. after closing the app from which I copied/selected, pasting and middle clicking doesn't work. Opening klipper and manually selecting the entry makes it work for both middle clicking and pasting. Also, even with "prevent empty clipboard" disabled, after closing kwrite (from the above example), I still see the text in the klipper history list..
@Ahmad: The last bit is expected. It shouldn't have a checkbox beside it though, and it shouldn't be pastable. Would it perhaps be more intuitive if the top item was empty in this case? Frustratingly, I cannot reproduce your recipe with KWrite replaced by Kate, but I will try again tomorrow with your exact recipe and all the versions of klipper I have available. I REALLY appreciate the recipes, I want this bug nailed as much as anyone. In the meantime, could you tell me the exact version of KDE / klipper you are using?
I made a mental note to state what version I use when I was typing my comment but forgot.... Anyway, this is with KDE4.3.98, with klipper 0.9.7. (In reply to comment #7) > @Ahmad: The last bit is expected. It shouldn't have a checkbox beside it > though, and it shouldn't be pastable. Would it perhaps be more intuitive if the > top item was empty in this case? > It doesn't have a checkbox beside it and it's not paste-able without manually selecting it. I just posted that as an observation, that with or without "prevent empty clipboard" the behaviour is the same. I tested kate, same behaviour.
I can reproduce this now :D Will look at it soon, as the baby allows.
Wonderful. This seems to be QT problem... QClipboard doesn't report when the clipboard is emptied, as far as I can see. This will take some extra digging.
Thanks for looking into this (and give my regards to the baby :)).
Any progress? I can still see it happening on 4.4.2.
I will close the bug when I get a fix in :) I have an idea, and some code, but no fix yet.
This looks fixed, with kde4.5rc1 and qt-4.7.0: $ kde4-config -v Qt: 4.7.0 KDE Development Platform: 4.4.90 (KDE 4.4.90 (KDE 4.5 RC1)) kde4-config: 1.0 Now I can: - open a text file with e.g. kwrite - copy or highlight some text and close kwrite - then go to any other app and paste or middle click (depending on whether I copied or only highlighted) the text.
I'm using 4.10.1 and have run into the same problem. Sometimes pasting does not work yet the item is in the history at the top of the list. I have not tried to perfectly duplicate the problem, but I seem to encounter the problem most often when pasting text into a dialog text box. My relevant klipperrc options: [General] IgnoreSelection=true MaxClipItems=25 Number of Actions=0 PreventEmptyClipboard=false Version=0.9.7 Thanks. :)
Just a comment, I'm unable to reproduce the problem anymore for quite some time. And now with plasma5, where klipper is replaced with plasmoid... feel free to close this one as 'obsolete' unless people who commented have some objections.
This is still very much a problem. Tested using the keyboard-triggered menu at cursor position.
Here's a simple way to reproduce: 1. select text, copy 2. select new text, do not copy 3. trigger at-cursor clipboard menu, click top entry. it is the selected-but-not-copied text
Easily reproducible on plasma-workspace-5.7.5-2.fc24.x86_64. Ignore selection = no Text selection only = yes Synchronize = no 1) Open kate 2) write "word1 word2" in kate 3) double click on word1 4) Ctrl-C 5) double click on word2 6) move cursor away from selection (e.g. an empty line) 7) Ctrl-V: word1 is pasted (__CORRECT!__) 8) Ctrl-Alt-V: opens klipper history menu, first entries are word2 and word1, the highlighted line is word2, I press enter 9) Ctrl-V: word1 is pasted (__WRONG__, I've just chosen word2 in step 8!) 10) Ctrl-Alt-V: the history still has word2 on top, I go down, go up, press enter, try pasting with Ctrl-V again: __WRONG__ I still get word1 11) Ctrl-Alt-V: the history still has word2 on top, I go down to a random entry and press enter, then Ctrl-Alt-V again, go to word2, press enter; I now paste and I get word2 (__CORRECT__, but I had to choose something else before choosing the string I wanted) For some reason the Enter on the first entry has no effect. (and I've never understood the meaning of the checkbox sometimes appearing on first entry.) This is not kate specific, the problem is in klipper.
As per comment #16, the original problem. The other problems appear to be unrelated and are e.g. bug #348390.
As per comment #16, the original problem can no longer be reproduced. The other problems appear to be unrelated and are e.g. bug #348390.