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 Jones
RWS@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