Version: (using Devel) Installed from: Compiled sources OS: Linux When I copy something (using ctrl+c), for instance in eclipse - I usually have to press the key combination twice before klipper/the kde clipboard remembers what I copied. This can be insanely frustrating when the application/document/file you copied from is closed and the clipboard didn't copy the selected text.
There are several people in our office which observe the same behaviour in multiple versions of eclipse and the Zend development environment. Running Mandriva 2009. KDE 4.1.3 It also occurs for Ctrl+x. This behaviour does not occur under other desktop managers (e.g. Gnome).
More information. It appears to be some interaction with Klipper. If Klipper is stopped then the problem vanishes.
It's also "fixed" if you uncheck the "prevent empty clipboard" setting in klipper configuration.
I'm seeing this too, using KDE 4.2.0. I sometimes trigger it using KDE apps like konqueror/kate only. The problem is a bit different for me: If I press CTRL+C only once, move to another window and press CTRL+V, it will sometimes output the previous value from the clipboard. When I then open klipper, it shows that it actually copied the selected data as the first entry. Somehow it's not "activated"? "Prevent empty clipboard" is currently enabled, though I already tried turning various settings on and off. I've now upgraded to KDE 4.2.1 and will try to reproduce it. Any hint what could go wrong in this scenario?
A couple of questions to reporters: 1. Do you have a actions enabled? 2. Does this gets fixed if you disable actions? 3. What's the state of "Syncronize clipboard and selection" option?
1: I don't now, but it didn't make any difference when I had them enabled. I only turned them off because klipper died when I tried using any of the actions it provided (copy link, click "open in firefox", watch klipper die) - but that's a different story. 2: no. 3: It's off, the other option (separate clipboard and selection) is selected. Like mentioned before - usually what I do after installing klipper is turn off "Prevent empty clipboard", and the problem is no more. Might be something happening in the backend, but at least that always fixes it.
*** Bug 168730 has been marked as a duplicate of this bug. ***
A link from bug 168730 which can be useful: http://techtavern.wordpress.com/2008/08/10/fixing-copy-paste-issues-on-eclipse-and-kde/
*** Bug 174820 has been marked as a duplicate of this bug. ***
*** This bug has been confirmed by popular vote. ***
"It's also "fixed" if you uncheck the "prevent empty clipboard" setting in klipper configuration." I cannot confirm this.
(In reply to comment #11) > "It's also "fixed" if you uncheck the "prevent empty clipboard" setting in > klipper configuration." > I cannot confirm this. You're right, that fixes the problem for me, but if it's a Klipper bug then I think it should be fixed, no matter whatever workaround is possible, isn't it? It's really annoying :( KDE 4.2.4 Klipper 0.9.7 Eclipse 3.4.2
*** Bug 190871 has been marked as a duplicate of this bug. ***
I have investigated the problem a litte. This is probably not fault of klipper, but of qt. Klipper uses the class "QClipboard" to get the content of the clipboard. The problem lies there. QClipboard does not copy the selection - so klipper cannot have it too. I reported the bug upstream. Let's see.
I believe this is related to the following bug: https://bugs.kde.org/show_bug.cgi?id=199333
Yeah, a qt quy just answered that too. I'm not sure. This is a patch for qt 4.5.2. http://qt.gitorious.org/qt/qt/commit/9e5fa633913ef952ca4ef5312fe396bcfc885321 Is anyone running a self compiled qt and wants to check that?
That patch doesn't fix the the Eclipse+Klipper clipboard bug.
(In reply to comment #17) > That patch doesn't fix the the Eclipse+Klipper clipboard bug. Does you Klipper run with a patched Qt? Since klipper also uses QClipboard, it is necessary to make sure it runs with the patch. I cannot reproduce the problem with Qt master branch in openSUSE 11.1 (KDE 4.1.3, klipper 0.9.7, eclipse galileo 3.5.0) - i.e. all kde apps are running against Qt 4.4.3 and I test copy/paste in textedit demo from Qt master.
I'm still experiencing this problem on my recently upgraded laptop: KDE 4.3.0 Qt 4.5.2 Klipper 0.9.7 Eclipse 3.5 (Galileo)
Me too, but not all the time. I have to figured out in what situations this happens.
The same here. Ctrl+c ctrl+v works in Zend, FF, but doesn't in mc and VLC. Copy and paste in mc works only inside mc application. KDE 4.3.1 QT 4.5.2-2
please do something about that - although it looks like a small issue its really bothering at daily work.
same here with kde 4.3.1 qt 4.5.2-2 (debian sid) kde apps stop at some point (could not yet determine when) to have working copy paste. seems all non kde-apps (including pure qt or pyQt apps) still work.
Same here, same versions. But I have also problems with openoffice. Clipboard only works with Shift-ENF and Shift-Insert. May be a OO.org problem, but I remember that this behaviour changed after an update where OO.org was not involved.
I can confirm this on KDE 4.3.2. Here's an easy test that works for me every time: 1) I open Kwrite (I will be pasting into this later). 2) I open an OpenOffice.org spreadsheet that contains text in the fields (in my case, e-mail addresses). 3) I click on a text field to copy, press CTRL-C and then I immediately move my mouse over the plasma panel... it's unresponsive. The panel will stays unresponsive for about 6 seconds. (The panel freeze doesn't always happen, but it does more often than not.) 4) I switch to Kwrite and press CTRL-V to paste. Nothing. (A quick peek at Klipper shows that the text was not copied from OOo, and a blank entry stands at the top of the list.) 5) I go back to the OOo spreadsheet and press CTRL-C again. 6) Switch back to Kwrite and this time, it finally pastes the data. Now, if I close Klipper, copying and pasting seems to work fine; however, I still get the panel freezes when copying data. ** My System ** Motherboard: MSI K9N SLI Platinum (nForce 570 SLI chipset) CPU: AMD Athlon(tm) 64 Processor 4000+ RAM: 2GB DDR2 Video: Dell NVIDIA GeForce 7800 GTX w/ 256 MB RAM (PCI Express) OS: Kubuntu 9.04 i386 (with KDE 4.3.2) Linux Kernel: 2.6.31-6-rt NVIDIA driver: 185.18.36 X.org: 7.4
I should have mentioned that I'm using the Sun build of OpenOffice.org 3.1.1 with KDE3 integration, if that makes any difference.
For me, I don't even need to use a non-KDE app. In Konsole, attempting a select with mouse and paste using middle click only works every second time. In fact, of all the KDE apps, Konsole is the one that displays this behaviour (i.e. copying in such a way that Klipper won't accept the content) most often. I should mention that I tend to use yakuake instead of Konsole, but that doesn't make a difference.
I have disabled actions, all configurable options except for "sync selection and clipboard". When copying from Konsole or some other application (TCL/Tk ones are most affected) doesn't work, I have found that clearing klipper's history fixes issue. Still remembering to clear history before copying important data is a huge PITA. KDE 4.3.3 on ~AMD64 Gentoo running Klipper v0.9.7 x11-libs/qt-core-4.5.3
Please fix this, it has been open far too long - and has quite a lot of votes.
This is an eclipse bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=153809. It seems to be on it's way to be patched, so that is good. For future reference, the broken gtk function is "gtk_clipboard_set_with_data()" and the working one is "gtk_clipboard_set_with_owner()".
*** Bug 208325 has been marked as a duplicate of this bug. ***
(In reply to comment #30) > This is an eclipse bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=153809. It > seems to be on it's way to be patched, so that is good. If this is purely an eclipse bug, why are KDE-applications affected, too? (For me, yakuake, konsole and kopete are most affected.)
This is absolutely NOT Eclipse only. I have this bug, and I never used Ecplipse... I noticed it seems to occur when source app is closed.
I think this has to be sorted out properly. There have been fixes comming with qt 4.6 (currently in Beta). Since the beta packages have come in Kubuntu on Sunday, I have none of those problems related to KDE apps. The problem still seems to exists with Firefox and Adobe Reader however. With Yakuake and Konsole it should be kept in mind that there are different short-cuts for Clipboard than normally in KDE (CRTL-SHIFT-v/c/x). So to check this, I would suggest everyone have this problem to install qt4.6, to see if the problem this exists. With Firefox and Adobe Reader the problem appears like this. I have to copy everything 2 times to clipboard, so that it is in there. So Firefox and Adobe Reader may have the same bug as in Eclipse. There is however a simular bug with Firefox, when doing a "send link". It takes ages until Kmail finally opens a composer window. So I assume the communication between KDE and non-KDE apps may be very, very slow. So may be the bug is also caused by this.
What seems interesting and indicates that there is still a bug on KDE side is the fact, that when I copy an URL in Firefox to clipboard, that clipboard action menu pops up always the first time I copy it. But still, the url can not be found in Klipper. Klipper is set to ignore selection and to keep clipboard and selection separated. I have deactived clipboard actions for a moment. This has an interesting effect: The clipboard works without problems with Firefox and Adobe Reader. When I turn clipboard actions on again, the bug reappears. So the bug is reproducable now for me. I hope, this may help fixing it!
Sorry about that, I was hunting for eclipse duplicates yesterday, must have been too tired.
Would be great, if there could be a fix in the upcomming 4.3.4.
I can reproduce #25, and I did some digging. What happens is 1. Klipper is notified that the clipboard has changed 2. Klipper request the formats that the data is available in 3. Qt sends a request for the data to oocalc via. X 4. Qt waits for 5s 5. Qt gives up, and returns "no formats" 6. Klipper interprets this as an empty clipboard and resets to the top clipboard item. Upping the wait to 15s (say) cures the problem, but it is not really a solution (would introduce long waits). Introducing a wait for say 2s before requesting the data also works, but is also not a solution (would break other stuff). It is interesting that it is not every time that oocalc needs more than 5s to supply the information. I will mull this a bit. It seems to me that this is a fundamental problem with Qt's implementation of the clipboard on X11, and would be best fixed by ignoring this clipboard mechanism altogether. But that would mean quite a bit of code. This *might* also be what is happening in Konsole and friends, but I have not been able to reproduce the problem there. oocalc is pretty reliable, only taking 2-3 tries to get the broken behavior. I should send them a thank-you note. Thanks is certainly in order for S. Christian Collins for the steps-to-reproduce.
Hi Esben, did you try to reproduce what I suggested with qt 4.6? For me it seems like qt 4.6 has fixed some of the problems and the problem is now related to Klipper actions being enabled or not.
I can reproduce the bug using KDE apps : - Launch konqueror and kwrite - enter some text in kwrite - copy the text - close kwrite - paste in konqueror - this not work If I dont close kwrite it works as it should. Do you agree that I should be able to past my text even if the source app is closed ? Tested on KDE 4.3.2 (Qt 4.5) and 4.3.75 (Qt 4.6)
m.wege@web.de: Yes, I tested everything with qt 4.6-rc1 from kde-qt. I actually looked at the code, too, and it is fundamentally broken. Rémi: If you have "prevent empty clipboard" enabled, then yes, otherwise it is working as it should.
@Remi: I can reproduce what you decribe. Interestingly it does not matter, if the source app was closed, when I have already pasted the content.
"prevent empty clipboard" option is checked. I'll try to find another example with source app still opened ;)
Ok, I think I nailed it. At least I cannot reproduce the problems with my current code, while I can with my 4.3.3 install. There were 2 problems: 1. The aforementioned brokenness, that if an application took more than in 5s in supplying clipboard formats, klipper treated it as empty. I have made the worlds stupiest hack for this: I simply ask a second time if the clipboard appears empty. Qt caches the reply if it gets one, so that is almost the same as raising the timeout to 10s. Not perfect, but the perfect solution would be to ditch QClipboard all together, and I don't think that is a good idea. 2. Once upon a time (3.x?) QClipboard didn't know about XFixes, and Klipper did. So that worked alright. But now they both know, which resulted in some unfortunate behavior. So I have ditched the XFixes support in Klipper, relying on QClipboard alone, and it seems to work great. Hopefully, the beta-cycle of 4.4 will tell for sure. I will commit once I have straightened out my repository. If I get some confirms that this is actually working, it should appear in 4.4, and perhaps 4.3.4. if possible.
*** Bug 166282 has been marked as a duplicate of this bug. ***
SVN commit 1055587 by esben: Remove old XFixes support, which is now supported directly by QClipboard. Also doubles the timeout for checking whether the clipboard is empty, to avoid false positives. BUG: 166606 M +4 -0 clipboardpoll.cpp M +15 -12 klipper.cpp M +2 -3 klipper.h WebSVN link: http://websvn.kde.org/?view=rev&revision=1055587
It is either this commit, or the one for bug 189242, but klipper no longer works for me, it always did before. Now when I copy text from (say) Kate to clipboard, I can paste it, but Klipper menu still says "empty clipboard". This is with a fresh user.
SVN commit 1059041 by esben: Fix nothing added to history when history was empty BUG: 166606 M +3 -3 history.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1059041
Thanks a lot for solving this issue :)
Hi there I am running KDE Version 4.3.2 on the current Linux Kernel. I have very annoying problems with the Clipboard. It forgets or maybe doesn't copy text as it should do. This happens across all KDE Apps. I am these days particularly working with the current Eclipse due to trainig Java-Programming Language. I could automatically install it from the KDE built-in Add and Remove Software program. But for sure this bug happened before Eclipse, too. What is the solution? Because this bug seems to be marked as solved? Best regards, Sebastian Morkisch
The bugfix will be in KDE 4.4, so it's a matter of waiting a little bit more and upgrade to KDE 4.4 to receive this fix (if it is actually related to the Eclipse problem you describe).
Yippie-ka-yeah... Thank you very much for your response. Have a great day. :-) Best regards, Sebastian