oj@apollo.uucp (Ellis Oliver Jones) (03/27/88)
When issuing an XConvertSelection request, is it OK to use the
same Atom to name the selection, and to name the property
into which the selection's value is to be stored? That is,
can I do
XConvertSelection ( dpy, XA_PRIMARY, XA_STRING, XA_PRIMARY,
mywindow, timestamp );
Similarly, is it OK to use the target (data type) Atom as a property name?
On a slightly different topic, if the owner of a selection receives
a SelectionRequest event asking it to convert a selection to an unknown
target (meaning a target type that the owner doesn't recognize),
is it OK for the owner to translate to some arbitrary fallback target type (such as
XA_STRING), then return the fallback target to the requestor in the SelectionNotify
event?
From the protocol spec. and Xlib, it looks like these operations should work.
Do they violate conventions?
Regards,
/Ollie JonesRWS@ZERMATT.LCS.MIT.EDU (Robert Scheifler) (04/03/88)
Date: 26 Mar 88 21:07:00 GMT
From: apollo!oj@eddie.mit.edu (Ellis Oliver Jones)
When issuing an XConvertSelection request, is it OK to use the
same Atom to name the selection, and to name the property
into which the selection's value is to be stored?
Similarly, is it OK to use the target (data type) Atom as a property name?
Yes. Since the property will be stored on your window, you are free to
choose any property name you like.
However, when implementing selections in a generic way (e.g., the selection
routines being worked on for Xt), either such static choice will get you
into trouble if there are simultaneous conversions in progress. A better
approach is to gensym atoms on the fly (but reuse them, to avoid eating up
server resources). Note that, although the draft conventions manual suggests
that clients use None for the property name, a number of us now believe that
it is better for the client to always provide the property name, since the
client is in a better position to know what property names are in use on
its own windows.
On a slightly different topic, if the owner of a selection receives
a SelectionRequest event asking it to convert a selection to an unknown
target (meaning a target type that the owner doesn't recognize),
is it OK for the owner to translate to some arbitrary fallback target type (such as
XA_STRING), then return the fallback target to the requestor in the SelectionNotify
event?
No, this might well confuse the requestor. For example, the requestor
might make to conversions simultaneously, and might expect to use the
<selection,target> pair to distinguish the replies. The conversion
should simply fail. A requestor that cared could ask for TARGETS (see
the conventions manual), and decide whether to ask for an alternate
target.diamant@hpfclp.HP.COM (John Diamant) (04/05/88)
> > On a slightly different topic, if the owner of a selection receives > > a SelectionRequest event asking it to convert a selection to an unknown > > target (meaning a target type that the owner doesn't recognize), > > is it OK for the owner to translate to some arbitrary fallback target type > > (such as XA_STRING), then return the fallback target to the requestor > > in the SelectionNotify event? > > The draft manual I mentioned above says to do exactly that. Please ignore my comment above. Of course, RWS is correct; you aren't supposed to return a different type than what was requested. I'm not sure whether I was remembering something I read in an earlier draft of the conventions manual or with other similar selection systems. Sorry for the confusion. The current draft of the conventions manual says to refuse the selection request if the target is not supported. John Diamant SDE UUCP: {hplabs,hpfcla}!hpfclp!diamant Hewlett-Packard Co. ARPA Internet: diamant%hpfclp@hplabs.HP.COM Fort Collins, CO