Bug 120846

Summary: klipper creates a bitmap rather than a text copy
Product: [Unmaintained] klipper Reporter: David Liontooth <liontooth>
Component: generalAssignee: Esben Mose Hansen <kde>
Status: RESOLVED FIXED    
Severity: normal    
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: unspecified   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description David Liontooth 2006-01-27 04:44:01 UTC 
Version:           unknown (using KDE 3.5.0, Debian Package 4:3.5.0-3 (testing/unstable))
Compiler:          Target: x86_64-linux-gnu
OS:                Linux (x86_64) release 2.6.14

When trying to copy text from one slide to another in OpenOffice.org Impress, klipper creates bitmaps of the text areas as they are selected. These bitmaps are useless and hinder effective copy and paste of text in Impress. It is now almost impossible to copy text from one slide to another.

This bug report is related to Bug 101087, which complains about the creation of multiple bitmaps in various applications, especially OOo.

This bug report points out that even the creation of a single bitmap is the context of OOo Impress text slides makes no sense, unless specially requested. 

The default action should be one of the following:

 * provide a parameter in klipper's configuration panel that turns image copy on and off (preferable solution)
 * wait to copy something until text is selected, unless a special command to copy an image is given

Please have a look at this -- the companion bug 101087 has been around for nearly a year.

Dave
Comment 1 Lubos Lunak 2006-01-31 14:54:51 UTC 
Well, Klipper copies those bitmaps because OOo puts them in the selection clipboard. Klipper doesn't make things out of the blue, it simply keeps a history of whatever apps put in the clipboard.
I've added a klipperrc:[General]:SelectionTextOnly option defaulting to true that disables keeping track of anything else than text in the selection clipboard (i.e. MMB copy&paste, as opposed to the normal clipboard). Selection doesn't make much sense for anything else than text anyway. Will be available with 3.5.2.
Comment 2 David Liontooth 2006-01-31 18:17:58 UTC 
Fantastic -- kudos for taking care of this so quickly and expertly. 

Clarification question: I'm not sure I fully understand the dynamics between the selction clipboard and the normal clipboard. Does this fix mean that images marked in applications that have implemented the TIMESTAMP feature can be copied and pasted as before, while images marked by other applications and obtained through polling by Klipper will now be dropped?

Since this is a parameter file value, it should be a straightforward matter to add an option in Klipper's configuration menu. I propose adding as follows after "Prevent empty clipboard" and before "Ignore selection":

      Select text only (ignore images)

After your precise diagnosis, OOo and Gnuplot should be able to fix their side of the story. 

Once they do, does that mean it will be possible to copy items from these applications into KDE apps without the use of polling (which your patch for bug 101087 switches off)? If so, image copy would potentially become useful again also in these applications.
Comment 3 Lubos Lunak 2006-02-01 15:40:28 UTC 
See http://standards.freedesktop.org/clipboards-spec/clipboards-0.1.txt for the difference between the two keyboards. This option prevents Klipper from copying anything else than text from PRIMARY. Option from bug #109032 disables non-text completely.
I cannot add GUI option for this for 3.5 because of string freeze.
Workaround from #101087 prevents only unnecessary repeated data transfers caused by the missing TIMESTAMP targets.