Re: clipboard & klipper in X11 terminal

[Ethan M. <merritt@u.washington.edu>]

On Thursday 02 February 2006 06:20 am, Timoth=E9e Lecomte wrote:
> Interesting entry today on the blog of one of the klipper developpers
>
> http://www.kdedevelopers.org/blog/280
> title =3D "why klipper is good"
>
> Basically he describes how the clipboard works in X since the early
> ages and how klipper manages to handle a history of clipboard
> contents. He explains why there can be so much copies of a bitmap in
> klipper.=20

Thank you for pointing this out.
I will have to read that and the related links carefully when
I next have some free time.

> Indeed gnuplot is quoted as a problematic app here :
> http://bugs.kde.org/show_bug.cgi?id=3D101087
> The proposed solution is to set TIMESTAMP.=20

I will explore setting XA_TIMESTAMP as an explicit target,
but I am dubious that this will fix anything by itself.

You later quote the following with regard to TIMESTAMP:
  "Clients should not set the time value to CurrentTime"
As you point out, we are using CurrentTime in gnuplot_x11.

It is hard for me to understand what sense it makes to call
something a "timestamp" if it does not, in fact, contain the
current time.

However,....
I don't think this is the problem.  The failure mode described in
the section you quote is that the client [gnuplot_x11 in this case]
may not properly obtain ownership.  That is not what I see happening.
We gain ownership just fine.  The problem is that if we do not
explicitly *relinquish* ownership, then klipper keeps sending
its requests over and over again.  I think this cannot be correct
behaviour by klipper.  It should request once, and only [maybe]
request again if the first request fails.

> I don't know much more unfortunately. Details here :
> http://tronche.com/gui/x/icccm/sec-2.html#s-2.6.2
> And by the way he implemented a workaround for apps that don't set
> TIMESTAMP which will be included in kde 3.5.2

Meanwhile, I have updated gplt_x11.c in CVS to separately request
export of either the mouse coordinate string or the pixmap+colormap,
but not both at the same time.  This seems to make klipper happier,
since it now notices the the string export whereas before it did not.
However, I still find it necessary to explicitly remove gnuplot_x11 from
the selection list after replying once; otherwise klipper loops
ad nauseum.

Update:
A very quick test indicates that even if I set XA_TIMESTAMP as a target,
klipper never requests it.  So I think that diagnosis is wrong.  I=20
tried:

static Atom targets[] =3D { XA_PIXMAP, XA_COLORMAP, XA_TIMESTAMP };
=2E..
XChangeProperty(dpy, reply.xselection.requestor,
                                reply.xselection.property,
                                reply.xselection.target,
                                32, PropModeReplace, targets, 3);
=2E..
            } else if (reply.xselection.target =3D=3D XA_TIMESTAMP) {
                fprintf(stderr, "TIMESTAMP request\n");

The fprintf never triggers.
Maybe I've done something wrong, but that code fragment is exactly
parallel to the XA_PIXMAP and XA_STRING target code that is already
working.

=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA