Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!pasteur!ucbvax!ZERMATT.LCS.MIT.EDU!RWS
From: RWS@ZERMATT.LCS.MIT.EDU (Robert Scheifler)
Newsgroups: comp.windows.x
Subject: Selections, Targets, Properties, Atoms ?
Message-ID: <880402161847.6.RWS@KILLINGTON.LCS.MIT.EDU>
Date: 2 Apr 88 21:18:00 GMT
References: <3b170d54.d5b2@apollo.uucp>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 35


    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.