|
From: Dave D. <dde...@es...> - 2006-07-21 09:27:35
|
Daniel J Sebald <dan...@ie...> writes:
> Good news. I believe I have solved the "sometimes transfers, sometimes d=
oesn't" bug.
>
> I've come back to my original concern, which was the MULTIPLE target. Cu=
rrent CVS gnuplot doesn't address that. It returns None for the property. =
However, documentation says that like TIMESTAMP, MULTIPLE should be handle=
d. And properly addressing that (if only partially) seems to have fixed th=
e "sometimes copies, sometimes doesn't" bug.
>
It would certainly make it more efficient, since apps seem to try
MULTIPLE even for a single target. I suspect that the Xt libraries are
doing this, rather than the apps doing it explicitly.
> } else if (reply.xselection.target =3D=3D XA_MULTIPLE) {
>
> Atom *atom =3D &reply.xselection.property;
>
> if (atom[0] =3D=3D None)
> reply.xselection.property =3D None;
> else {
> int i;
> for(i=3D0; atom[2*i] !=3D None; i++) {
>
I don't think you can treat propery as an array of atoms. You must
retrieve the current value of the property, and that returns an array
of atoms. The number of atoms is given by the length of the property.
Googling for XA_MULTIPLE found some source to demonstrate this :
http://mi.eng.cam.ac.uk/~er258/code/dist/x_clipboard/selection.cc
>
> (Technically, MULTIPLE can be anything, so really it should be outside th=
e case statement and not one of the cases... can fix later. I don't think =
many apps will stuff all their requests into a single multiple.)
>
> So, properly responding to MULTIPLE seems to help. But I don't think I h=
ave it quite yet. What concerns me is this MULTIPLE and its atom PRIMARY:
>
> selection request: TARGETS (324) for PRIMARY (1) targets 2
> selection request: MULTIPLE (325) for PRIMARY (1)
> atom PRIMARY (1) : prop 51527025
> atom PRIMARY (1) : prop 51527025
> selection request: PIXMAP (20) for PRIMARY (1)
> selection request: COLORMAP (7) for PRIMARY (1)
>
> The documentation is very sparse on what exactly this property
PRIMARY is supposed to be in the context of MULTIPLE. Anyone have
any idea? (I'd be most grateful!)
As far as I can see, this is covered in the ICCCM, which is the bible
of all things cut/paste
eg
http://tronche.com/gui/x/icccm/sec-2.html#s-2.6.2
The propery contains a list of pairs of atoms, 2*i is the selection,
and 2*i+1 is the type. It is as if the client sent n requests.
> Is it an address of an existing buffer on the requestor's window?
IIRC (it's been a long time) the propery is reused : normally, the
requestor names the property they want the value written into. With
MULTIPLE, the client prefills that property with the types they
want. So the selection owner reads the property to find what the
originator wants.
> Does it want the handler to DELETE the PRIMARY buffer? Is it so
> obvious I can't see what it is?=20
>
> Timoth=E9e, Dave and Bob. Could you please give Patches item #1523316 a =
try if you have time? I'd like your comments.
>
> Dave, are you the "drd" of this comment?
>
Almost certainly.
> /* drd : export the graph via ICCCM primary selection. well... not quite
> * ICCCM since we dont support full list of targets, but this
> * is a start. define EXPORT_SELECTION if you want this feature
> */
>
> What are your thoughts on getting rid of this EXPORT_SELECTION
> on/off variable? My feeling is the mouse/key press route is more
> X11 convention. Also, if we want something like selection when
> plotting, a "set output clipboard" could take its place.=20
>
It's entirely historical. In a sense, I misused my position of gnuplot
maintainer at the time, and only added the selection stuff to test the
corresponding paste code I was working on in my day job (Softwindows
and NTRIGUE at Insignia). So making it a compile-time conditional was
just so that my private code didn't affect other people.
The mouse click / keypress would give you an X event with a real
timestamp, which solves all the CurrentTime issues.
dd
--=20
Dave Denholm <dde...@es...> http://www.esmertec=
.com
|