Version: (using KDE Devel) Installed from: Compiled sources OS: Linux even if "Prevent empty clipboard" is on. To reproduce: 1. open KolourPaint 2. draw something 3. select it and Edit/Copy 4. exit KolourPaint 5. bring up a new KolourPaint and Edit/Paste You either get nothing or text (I'm guessing it's the last text entry in the klipper history). Either way, QImageDrag::decode() returns false on QApplication::clipboard ()->data (QClipboard::Clipboard).
Yes, the "prevent empty clipboard" only works for text. I'm changing this, but it'll be a while before it is complete. You are in luck though: Image support is high on my list :)
Well, the commit I'm going to make adds support in Klipper for images. But KolourPaint does not handle this well at all for some reason. The ancient KPaint have no trouble, except discovering that the clipboard actually contains an image, so I know that Klipper correctly sets an image, but KoulourPaint just pastes some text instead. Some day, copy&pasting images in Linux will just work. Some day :) This bug will stay open until I am reasonable sure that "prevent empty clipboard" works for all applications --- as seen from Klipper's point of view.
On Tue, 23 Nov 2004 08:20 am, Esben Mose Hansen wrote: > Well, the commit I'm going to make adds support in Klipper for > images. Could you please let me know after you've done the commit? > The ancient KPaint have no trouble, except discovering that the clipboard > actually contains an image, If KPaint doesn't realise that there isn't an image in the clipboard, how does KPaint paste it!? > so I know that Klipper correctly sets an image, > but KoulourPaint just pastes some text instead. That meant that KolourPaint couldn't see the image in the clipboard. If you could set DEBUG_KP_SELECTION_DRAG to 1 in kdegraphics/kolourpaint/kpselectiondrag.cpp and send me the debug output, that would be great. Else, I'll debug it when I have time (and when HEAD actually compiles :)). > Some day, copy&pasting images in Linux will just work. Some day :) BTW, if you could add "Copy" to the image RMB menu in KHTML, that would be great.
Nailed the thing about Kolourpaint. It turned out that Klipper could not set a image clipitem unless the item already in the clipboard was also an image item. It's fixed now in CVS. (toplevel version 1.167)
On Fri, 26 Nov 2004 05:37 pm, Esben Mose Hansen wrote: > Nailed the thing about Kolourpaint. It turned out that Klipper > could not set a image clipitem unless the item already in the clipboard was > also an image item. It's fixed now in CVS. (toplevel version 1.167) Great :) Does this handle "application/x-kolourpaint-selection" data as well (or any other application specific clipboard data)?
No, it only handles the image types and text. When it handles the rest, I'll close this bug :)
See also http://freedesktop.org/wiki/ClipboardManager .
What's the progress?
The support for images was added, but removed again due to various problems. I can't recall the exact details, sorry.
Any plans to reimplement it?
As far as I am aware, not in the short term
If you deselect "ignore images", does klipper do what you want?
By unchecking "Ignore images" it works, as reported in the post above mine.
Even after many moons, this is still an issue, needs investigating.
The solution is to uncheck "Ignore images". Without that, Klipper is simple doing what you tell it: ignoring images. So when you copy the image, it's getting ignored by Klipper and instead placed on the internal X11 clipboard, which clears itself automatically when the source app quits. If you want image data to be retained across app launched, you need to use Klipper for image pastes, which is accomplished by unchecking the "Ignore Images" checkbox. The question of whether this is a good default setting or not is another matter, of course. :)