Re: Weird KDE/QT clipboard behavior?

[Owen Taylor <otaylor redhat com>]

On Tue, 2003-08-26 at 10:12, Hongli Lai wrote:
> I'm trying to write a clipboard daemon for GNOME that keeps the contents of 
> the clipboard in memory even after an app has already closed. I noticed that 
> my daemon breaks KDE apps.
> 
> Upon investigation, I found out that the TARGETS atom set by KDE apps appears 
> to be invalid. I use the GTK+ function gtk_selection_data_get_targets(), 
> which retrieves a list of atoms from the clipboard owner by reading the 
> TARGETS atom. This function checks for the following things:
> - The selection data's length is greater than 0.
> - The format is 32.
> - The selection type is of type ATOM (4).
> This last check fails. The TARGETS atom set by KDE apps is named "TARGETS", 
> but it's numbered 92, not 4.
> I tried to force the type to GDK_SELECTION_TYPE_ATOM (4). The function 
> succeeded, but the resulted list contains mostly invalid atoms. The *only* 
> valid atom in that list is the atom STRING.
> After more investigation, I found that KDE apps do set a UTF8_STRING atom, but 
> that atom doesn't appear in the list of TARGETS.
> 
> I also just noticed that when I copy some text in KMail (or any other KDE 
> app), and rightclick on a text entry in a GTK+ 2 app, the Paste menu is 
> disabled (because gtk_selection_data_get_targets() returns FALSE). But the 
> pasting *does* work, because if I press Ctrl+V, the copied text pastes just 
> fine. COMPOUND_TEXT and UTF8_STRING are set correctly by KDE apps, but they 
> just don't appear in the list of TARGETS.
>
> Is there a reason why TARGETS appears to be invalid? Am I doing something 
> wrong or is the KDE clipboard a little broken?

The type of TARGETS is a Qt bug; See list on page 12-13 of the ICCCM
which gives the proper type for TARGETS as ATOM. Could you:

 A) File a GTK+ bug in bugzilla.gnome.org asking for GTK+ to be
    liberal in what it accepts for this. 

 B) Report a bug against Qt about the type of TARGETS (it might just
    be a KDE bug, you'd have to do some investigation - try it with
    a pure-Qt app not running in the KDE desktop to be sure.)

The reason why "forcing the type" probably didn't work was likely 
X atom => GdkAtom conversion wasn't happening... STRING came through
OK since for standard atoms no conversion is necesary. (GDK uses
atom values that don't directly correspond to X atoms to allow the
same atoms to be used on all displays for multihead.)

The reason why C-v works is that the GtkTextView just goes ahead and
asks for the data rather than for asking for TARGETS.

There was already someone working on a xclipboard/klipper like app
for GNOME, though I forget the details.

Regards,
					Owen