ICCCM - Peer-to-Peer Communication by Means of Selections
Peer-to-Peer Communication by Means of Selections
Selections are the primary mechanism that X Version 11 defines
for the exchange of information between clients,
for example, by cutting and pasting between windows.
Note that there can be an arbitrary number of selections
(each named by an atom) and that they are global to the server.
discusses the choice of an atom.
Each selection is owned by a client and is attached to a window.
Selections communicate between an owner and a requestor.
The owner has the data representing the value of its selection,
and the requestor receives it.
A requestor wishing to obtain the value of a selection provides the following:
The name of the selection
The name of a property
The atom representing the data type required
Optionally, some parameters for the request
If the selection is currently owned,
the owner receives an event and is expected to do the following:
Convert the contents of the selection to the requested data type
Place this data in the named property on the named window
Send the requestor an event to let it know the property is available
Clients are strongly encouraged to use this mechanism.
In particular,
displaying text in a permanent window without providing the ability
to select and convert it into a string is definitely considered antisocial.
Note that all data transferred between an owner and a requestor must usually
go by means of the server in an X Version 11 environment.
A client cannot assume that another client can open the same files
or even communicate directly.
The other client may be talking to the server by means of
a completely different networking mechanism (for example,
one client might
be DECnet and the other TCP/IP).
Thus, passing indirect references to data
(such as file names,
host names and port numbers, and so on)
is permitted only if both clients specifically agree.
Acquiring Selection Ownership
A client wishing to acquire ownership of a particular selection
should call
SetSelectionOwner,
which is defined as follows:
SetSelectionOwner
selection :
TIMESTAMP or
CurrentTime
The client should set the specified selection to the atom that represents
the selection,
set the specified owner to some window that the client created,
and set the specified time to some time between the current last-change time
of the selection concerned and the current server time.
This time value usually will be obtained from the timestamp of the event
that triggers the acquisition of the selection.
Clients should not set the time
CurrentTime ,
because if they do so, they have no way of finding
when they gained ownership of the selection.
Clients must use a window they created so that requestors
can route events to the owner of the selection.
Convention
Clients attempting to acquire a selection must set the time value of the
SetSelectionOwner
request to the timestamp of the event triggering the acquisition attempt,
CurrentTime .
A zero-length append to a property is a way to obtain a timestamp for
the timestamp is in the corresponding
PropertyNotify
If the time in the
SetSelectionOwner
request is in the future relative to the server's current time
or is in the past relative to the last time the specified selection
changed hands, the
SetSelectionOwner
request appears to the client to succeed,
but ownership is not actually transferred.
Because clients cannot name other clients directly,
the specified owner window is used to refer to the owning client
in the replies to
GetSelectionOwner ,
SelectionRequest
SelectionClear
events, and possibly as a place to put properties describing the selection
in question.
To discover the owner of a particular selection,
a client should invoke
GetSelectionOwner ,
which is defined as follows:
GetSelectionOwner
selection :
Convention
Clients are expected to provide some visible confirmation
of selection ownership.
To make this feedback reliable,
a client must perform a sequence like the following:
SetSelectionOwner(selection=PRIMARY, owner=Window, time=timestamp)
owner = GetSelectionOwner(selection=PRIMARY)
if (owner != Window) Failure
SetSelectionOwner
request succeeds (not merely appears to succeed),
the client that issues it is recorded by the server as being the owner
of the selection for the time period starting at the specified time.
Responsibilities of the Selection Owner
When a requestor wants the value of a selection,
the owner receives a
SelectionRequest
event, which is defined as follows:
SelectionRequest
selection :
property :
requestor :
TIMESTAMP or
CurrentTime
The specified owner and selection will be the values that were specified in
SetSelectionOwner
The owner should compare the timestamp with the period
it has owned the selection and, if the time is outside,
refuse the
SelectionRequest
by sending the requestor window a
SelectionNotify
event with the property set to
(by means of a
request with an empty event mask).
More advanced selection owners are free to maintain a history
of the value of the selection and to respond to requests for the
value of the selection during periods they owned it
even though they do not own it now.
If the specified property is
the requestor is an obsolete client.
Owners are encouraged to support these clients by using the specified target
atom as the property name to be used for the reply.
Otherwise,
the owner should use the target to decide the form into which the selection
should be converted.
Some targets may be defined such that requestors can pass parameters
along with the request.
The owner will find these parameters in the
property named in the selection request.
The type, format, and
contents of this property are dependent upon the definition of the
If the target is not defined to have parameters, the owner
should ignore the property if it is present.
If the selection cannot be converted
into a form based on the target (and parameters, if any),
the owner should refuse the
SelectionRequest
as previously described.
If the specified property is not
the owner should place the data resulting from converting the selection
into the specified property on the requestor window
and should set the property's type to some appropriate value,
which need not be the same as the specified target.
Convention
All properties used to reply to
SelectionRequest
events must be placed on the requestor window.
In either case,
if the data comprising the selection cannot be stored on the requestor window
(for example, because the server cannot provide sufficient memory),
the owner must refuse the
SelectionRequest ,
as previously described.
See also .
If the property is successfully stored,
the owner should acknowledge the successful conversion
by sending the requestor window a
SelectionNotify
event (by means of a
request with an empty mask).
SelectionNotify
is defined as follows:
SelectionNotify
requestor :
selection, target :
property :
TIMESTAMP or
CurrentTime
The owner should set the specified selection, target, time,
and property arguments to the values received in the
SelectionRequest
(Note that setting the property argument to
indicates that the conversion requested could not be made.)
Convention
The selection, target, time, and property arguments in the
SelectionNotify
event should be set to the values received in the
SelectionRequest
If the owner receives more than one
SelectionRequest
event with the same requestor, selection, target, and timestamp, it must
respond to them in the same order in which they were received.
It is possible for a requestor to have multiple outstanding requests that
use the same requestor window, selection, target, and timestamp, and that
differ only in the property.
If this occurs, and one of the conversion
requests fails, the resulting
SelectionNotify
event will have its property argument set to
This may make it impossible for the requestor to determine which conversion
request had failed, unless the requests are responded to in order.
The data stored in the property must eventually be deleted.
A convention is needed to assign the responsibility for doing so.
Convention
Selection requestors are responsible for deleting properties whose
names they receive in
SelectionNotify
events (see ) or in properties with type MULTIPLE.
A selection owner will often need confirmation that the data comprising the
selection has actually been transferred.
(For example,
if the operation has side effects on the owner's internal data structures,
these should not take place until the requestor has indicated
that it has successfully received the data.)
Owners should express interest in
PropertyNotify
events for the specified requestor window
and wait until the property in the
SelectionNotify
event has been deleted before assuming that the selection data has been
transferred.
For the MULTIPLE request, if the different conversions require
separate confirmation, the selection owner can also watch for the deletion
of the individual properties named in the property in the
SelectionNotify
When some other client acquires a selection,
the previous owner receives a
SelectionClear
event, which is defined as follows:
SelectionClear
selection :
The timestamp argument is the time at which the ownership changed hands,
and the owner argument is the window the previous owner specified in its
SetSelectionOwner
If an owner loses ownership while it has a transfer in progress (that is,
before it receives notification that the requestor has received all the data),
it must continue to service the ongoing transfer until it is complete.
If the selection value completely changes, but the owner happens
to be the same client (for example, selecting a totally different
piece of text in the same xterm as before), then the client should
reacquire the selection ownership as if it were not the owner,
providing a new timestamp. If the selection value is modified, but
can still reasonably be viewed as the same selected object,
owner should take no action.
Giving Up Selection Ownership
Clients may either give up selection ownership voluntarily
or lose it forcibly as the result of some other client's actions.
Voluntarily Giving Up Selection Ownership
To relinquish ownership of a selection voluntarily,
a client should execute a
SetSelectionOwner
request for that selection atom, with owner specified as
and the time specified as the timestamp that was used to acquire the selection.
Alternatively,
the client may destroy the window used as the owner value of the
SetSelectionOwner
request, or the client may terminate.
In both cases,
the ownership of the selection involved will revert to
Forcibly Giving Up Selection Ownership
If a client gives up ownership of a selection
or if some other client executes a
SetSelectionOwner
for it and thus reassigns it forcibly,
the previous owner will receive a
SelectionClear
event. For the definition of a
SelectionClear
event, see .
The timestamp is the time the selection changed hands.
The specified owner is the window that was specified by the current owner
SetSelectionOwner
Requesting a Selection
A client that wishes to obtain the value of a selection in a particular
form (the requestor) issues a
ConvertSelection
request, which is defined as follows:
ConvertSelection
selection, target :
property :
requestor :
TIMESTAMP or
CurrentTime
The selection argument specifies the particular selection involved,
and the target argument specifies the required form of the information.
For information about the choice of suitable atoms to use,
The requestor should set the requestor argument to a wi
the owner will place the reply property there.
The requestor should set the time argument to the timestamp on the event
that triggered the request for the selection value.
Note that clients should not specify
CurrentTime .
Convention
Clients should not use
CurrentTime
for the time argument of a
ConvertSelection
Instead, they should use the timestamp of the event that caused the request
to be made.
The requestor should set the property argument to the name of a property
that the owner can use to report the value of the selection.
Requestors should ensure that the named property does not exist
on the window before issuing the
ConvertSelection
The exception to this rule is when the requestor intends to pass
paramet see below.
It is necessary for requestors to delete the property before issuing the
request so that the target can later be extended to take parameters without
introducing an incompatibility.
Also note that the requestor of a selection
need not know the client that owns the selection nor the window on which
the selection was acquired.
Some targets may be defined such that requestors can pass parameters
along with the request.
If the requestor wishes to provide parameters
to a request, they should be placed in the specified property on the
requestor window before the requestor issues the
ConvertSelection
request, and this property should be named in the request.
Some targets may be defined so that parameters are optional.
parameters are to be supplied with the request of such a target, the
requestor must ensure that the property does not exist before issuing
ConvertSelection
The protocol allows the property field to be set to
in which case the owner is supposed to choose a property name.
However, it is difficult for the owner to make this choice safely.
Conventions
Requestors should not use
for the property argument of a
ConvertSelection
Owners receiving
ConvertSelection
requests with a property argument of
are talking to an obsolete client.
They should choose the target atom as the property name to be used
for the reply.
The result of the
ConvertSelection
request is that a
SelectionNotify
event will be received.
For the definition of a
SelectionNotify
event, see .
The requestor, selection, time, and target arguments will be the same
as those on the
ConvertSelection
If the property argument is
the conversion has been refused.
This can mean either that there is no owner for the selection,
that the owner does not support the conversion implied by the target,
or that the server did not have sufficient space to accommodate the data.
If the property argument is not
then that property will exist on the requestor window.
The value of the selection can be retrieved from this
property by using the
GetProperty
request, which is defined as follows:
GetProperty
property :
AnyPropertyType
long-offset, long-length :
{0, 8, 16, 32}
bytes-after :
LISTofINT8 or LISTofINT16 or LISTofINT32
When using
GetProperty
to retrieve the value of a selection,
the property argument should be set to the corresponding value in the
SelectionNotify
Because the requestor has no way of knowing beforehand what type
the selection owner will use,
the type argument should be set to
AnyPropertyType .
GetProperty
requests may be needed to retrieve all the d
each should set the long-offset argument to the amount of data received so far,
and the size argument to some reasonable buffer size (see ).
If the returned value of bytes-after is zero,
the whole property has been transferred.
Once all the data in the selection has been retrieved
(which may require getting the values of several properties &
the requestor should delete the property in the
SelectionNotify
request by using a
GetProperty
request with the delete argument set to
As previously discussed,
the owner has no way of knowing when the data has been
transferred to the requestor unless the property is removed.
Convention
The requestor must delete the property named in the
SelectionNotify
once all the data has been retrieved.
The requestor should invoke either
DeleteProperty
GetProperty (delete==True)
after it has successfully retrieved all the data in the selection.
For further information,
Large Data Transfers
Selections can get large, which poses two problems:
Transferring large amounts of data to the server is expensive.
All servers will have limits on the amount of data that can be stored
in properties.
Exceeding this limit will result in an
error on the
ChangeProperty
request that the selection owner uses to store the data.
The problem of limited server resources is addressed by the following
conventions:
Conventions
Selection owners should transfer the data describing a large selection
(relative to the maximum-request-size they received
in the connection handshake) using the INCR property mechanism
Any client using
SetSelectionOwner
to acquire selection ownership should arrange to process
errors in property change requests.
For clients using Xlib,
this involves using the
function to override the default handler.
A selection owner must confirm that no
error occurred while storing the properties for a selection
before replying with a confirming
SelectionNotify
When storing large amounts of data (relative to maximum-request-size),
clients should use a sequence of
ChangeProperty (mode==Append)
requests for reasonable quantities of data.
This avoids locking servers up and limits the waste of data an
error would cause.
error occurs during the storing of the selection data,
all properties stored for this selection should be deleted
ConvertSelection
request should be refused (see ).
To avoid locking servers up for inordinate lengths of time,
requestors retrieving large quantities of data from a property
should perform a series of
GetProperty
requests, each asking for a reasonable amount of data.
Advice to Implementors
Single-threaded servers should take care to avoid locking up during large
data transfers.
Use of Selection Atoms
Defining a new atom consumes resources in the server
that are not released until the server reinitializes.
Thus, reducing the need for newly minted atoms is an important goal
for the use of the selection atoms.
Selection Atoms
There can be an arbitrary number of selections, each named by an atom.
To conform with the inter-client conventions, however,
clients need deal with only these three selections:
Other selections may be used freely for private communication among
related groups of clients.
The PRIMARY Selection
The selection named by the atom PRIMARY is used for all commands
that take only a single argument and is the principal means of communication
between clients that use the selection mechanism.
The SECONDARY Selection
The selection named by the atom SECONDARY is used:
As the second argument to commands taking two arguments
(for example, &exchange primary and secondary selections&)
As a means of obtaining data when there is a primary selection
and the user does not want to disturb it
The CLIPBOARD Selection
The selection named by the atom CLIPBOARD is used to hold data
that is being transferred between clients,
that is, data that usually is being cut or copied, and then pasted.
Whenever a client wants to transfer data to the clipboard:
It should assert ownership of the CLIPBOARD.
If it succeeds in acquiring ownership,
it should be prepared to respond to a request for the contents of the CLIPBOARD
in the usual way (retaining the data to be able to return it).
The request may be generated by the clipboard client described below.
If it fails to acquire ownership,
a cutting client should not actually perform the cut or provide feedback
that would suggest that it has actually transferred data to the clipboard.
The owner should repeat this process whenever the data to be transferred
would change.
Clients wanting to paste data from the clipboard should request
the contents of the CLIPBOARD selection in the usual way.
Except while a client is actually deleting or copying data,
the owner of the CLIPBOARD selection may be a single, special client
implemented for the purpose.
This client maintains the content of the clipboard up-to-date
and responds to requests for data from the clipboard as follows:
It should assert ownership of the CLIPBOARD selection
and reassert it any time the clipboard data changes.
If it loses the selection (because another client has some new data
for the clipboard),
it should:
Obtain the contents of the selection from the new owner by using the timestamp
SelectionClear
Attempt to reassert ownership of the CLIPBOARD selection
by using the same timestamp.
Restart the process using a newly acquired timestamp if this attempt fails.
This timestamp should be obtained by asking the current owner of the
CLIPBOARD selection to convert it to a TIMESTAMP.
If this conversion is refused or if the same timestamp is received twice,
the clipboard client should acquire a fresh timestamp in the
usual way (for example by a zero-length append to a property).
It should respond to requests for the CLIPBOARD contents in the usual way.
A special CLIPBOARD client is not necessary.
The protocol used by the cutting client and the pasting client
is the same whether the CLIPBOARD client is running or not.
The reasons for running the special client include:
Stability - If the cutting client were to crash or terminate,
the clipboard value would still be available.
Feedback - The clipboard client can display the contents of the clipboard.
Simplicity - A client deleting data does not have to retain it for so long,
thus reducing the chance of race conditions causing problems.
The reasons not to run the clipboard client include:
Performance - Data is only transferred if it is actually required
(that is, when some client actually wants the data).
Flexibility - The clipboard data may be available as more than one target.
Target Atoms
The atom that a requestor supplies as the target of a
ConvertSelection
request determines the form of the data supplied.
The set of such atoms is extensible,
but a generally accepted base set of target atoms is needed.
As a starting point for this,
the following table contains those that have been suggested so far.
Data Received
ADOBE_PORTABLE_DOCUMENT_FORMAT STRING [1]
APPLE_PICT APPLE_PICT [2]
BACKGROUND PIXEL A list of pixel values
BITMAP BITMAP A list of bitmap IDs
CHARACTER_POSITION SPAN The start and end of the selection in bytes
CLASS TEXT (see )
CLIENT_WINDOW WINDOW Any top-level window owned by the selection owner
COLORMAP COLORMAP A list of colormap IDs
COLUMN_NUMBER SPAN The start and end column numbers
COMPOUND_TEXT COMPOUND_TEXT Compound Text
DELETE NULL (see )
DRAWABLE DRAWABLE A list of drawable IDs
ENCAPSULATED_POSTSCRIPT STRING [3], Appendix H
ENCAPSULATED_POSTSCRIPT_INTERCHANGE STRING [3], Appendix H
FILE_NAME TEXT The full path name of a file
FOREGROUND PIXEL A list of pixel values
HOST_NAME TEXT (see )
INSERT_PROPERTY NULL (see )
INSERT_SELECTION NULL (see )
LENGTH INTEGER The number of bytes in the selection
LINE_NUMBER SPAN The start and end line numbers
LIST_LENGTH INTEGER The number of disjoint parts of the selection
MODULE TEXT The name of the selected procedure
MULTIPLE ATOM_PAIR (see the discussion that follows)
NAME TEXT (see )
ODIF TEXT ISO Office Document Interchange Format
OWNER_OS TEXT The operating system of the owner client
PIXMAP PIXMAP A list of pixmap IDs
POSTSCRIPT STRING [3]
PROCEDURE TEXT The name of the selected procedure
PROCESS INTEGER, TEXT The process ID of the owner
STRING STRING ISO Latin-1 (+TAB+NEWLINE) text
TARGETS ATOM A list of valid target atoms
TASK INTEGER, TEXT The task ID of the owner
TEXT TEXT The text in the owner's choice of encoding
TIMESTAMP INTEGER The timestamp used to acquire the selection
USER TEXT The name of the user running the owner
References:
Adobe Systems, Incorporated.
Portable Document Format Reference Manual.
Addison-Wesley, ISBN 0-201-62628-4.
Apple Computer, Incorporated.
Inside Macintosh, Volume V.
Chapter 4, &Color QuickDraw,& Color Picture Format.
ISBN 0-201-17719-6.
Adobe Systems, Incorporated.
PostScript Language Reference Manual.
Addison-Wesley, ISBN 0-201-18127-4.
It is expected that this table will grow over time.
Selection owners are required to support the following targets.
All other targets are optional.
TARGETS - The owner should return a list of atoms that represent
the targets for which an attempt to convert the current selection
will succeed (barring unforseeable problems such as
This list should include all the required atoms.
MULTIPLE - The MULTIPLE target atom is valid only when a property
is specified on the
ConvertSelection
If the property argument in the
SelectionRequest
and the target is MULTIPLE,
it should be refused.
When a selection owner receives a
SelectionRequest (target==MULTIPLE)
the contents of the property named in the request will be a list of atom pairs:
the first atom naming a target and the second naming a property
is not valid here).
The effect should be as if the owner had received a sequence of
SelectionRequest
events (one for each atom pair) except that:
The owner should reply with a
SelectionNotify
only when all the requested conversions have been performed.
If the owner fails to convert the target named by an atom
in the MULTIPLE property,
it should replace that atom in the property with
Convention
The entries in a MULTIPLE property must be processed in the order
they appear in the property.
For further information,
The requestor should delete each individual property when it has
copied the data from that conversion, and the property specified in the
MULTIPLE request when it has copied all the data.
The requests are otherwise to be processed independently, and they
should succeed or fail independently.
The MULTIPLE target is an
optimization that reduces the amount of protocol traffic between the
own it is not a transaction mechanism.
example, a client may issue a MULTIPLE request with two targets: a data
target and the DELETE target.
The DELETE target will still be processed
even if the conversion of the data target fails.
TIMESTAMP - To avoid some race conditions,
it is important that requestors be able to discover the timestamp
the owner used to acquire ownership.
Until and unless the protocol is changed so that a
GetSelectionOwner
request returns the timestamp used to acquire ownership,
selection owners must support conversion to TIMESTAMP,
returning the timestamp they used to obtain the selection.
Selection Targets with Side Effects
Some targets (for example, DELETE) have side effects.
To render these targets unambiguous,
the entries in a MULTIPLE property must be processed in the order
that they appear in the property.
In general,
targets with side effects will return no information,
that is, they will return a zero-length property of type NULL.
(Type NULL means the result of
InternAtom
on the string &NULL&, not the value zero.)
In all cases,
the requested side effect must be performed before the conversion is accepted.
If the requested side effect cannot be performed,
the corresponding conversion request must be refused.
Conventions
Targets with side effects should return no information
(that is, they should have a zero-length property of type NULL).
The side effect of a target must be performed before the conversion is accepted.
If the side effect of a target cannot be performed,
the corresponding conversion request must be refused.
The need to delay responding to the
ConvertSelection
request until a further conversion has succeeded poses problems
for the Intrinsics interface that need to be addressed.
These side effect targets are used to implement operations such as
&exchange PRIMARY and SECONDARY selections.&
When the owner of a selection receives a request to convert it to DELETE,
it should delete the corresponding selection
(whatever doing so means for its internal data structures)
and return a zero-length property of type NULL if the deletion was successful.
INSERT_SELECTION
When the owner of a selection receives a request to convert it to
INSERT_SELECTION,
the property named will be of type ATOM_PAIR.
The first atom will name a selection,
and the second will name a target.
The owner should use the selection mechanism to convert the named selection
into the named target and should insert it at the location of the selection
for which it got the INSERT_SELECTION request
(whatever doing so means for its internal data structures).
INSERT_PROPERTY
When the owner of a selection receives a request to convert it to
INSERT_PROPERTY,
it should insert the property named in the request at the location
of the selection for which it got the INSERT_SELECTION request
(whatever doing so means for its internal data structures).
Use of Selection Properties
The names of the properties used in selection data transfer are chosen by
the requestor.
The use of
property fields in
ConvertSelection
requests (which request the selection owner to choose a name)
is not permitted by these conventions.
The selection owner always chooses the type of the property
in the selection data transfer.
Some types have special semantics assigned by convention,
and these are reviewed in the following sections.
In all cases,
a request for conversion to a target should return either
a property of one of the types listed in the previous table for that target
or a property of type INCR and then a property of one of the listed types.
Certain selection properties may contain resource IDs.
The selection owner
should ensure that the resource is not destroyed and that its contents are
not changed until after the selection transfer is complete.
Requestors that
rely on the existence or on the proper contents of a resource must operate
on the resource (for example, by copying the contents of a pixmap) before
deleting the selection property.
The selection owner will return a list of zero or more items
of the type indicated by the property type.
In general,
the number of items in the list will correspond to the number
of disjoint parts of the selection.
Some targets (for example, side-effect targets) will be of length zero
irrespective of the number of disjoint selection parts.
In the case of fixed-size items,
the requestor may determine the number of items by the property size.
Selection property types are listed in the table below.
For variable-length items such as text,
the separators are also listed.
Type Atom Format Separator
APPLE_PICT 8 Self-sizing
ATOM 32 Fixed-size
ATOM_PAIR 32 Fixed-size
BITMAP 32 Fixed-size
C_STRING 8 Zero
COLORMAP 32 Fixed-size
COMPOUND_TEXT 8 Zero
DRAWABLE 32 Fixed-size
INCR 32 Fixed-size
INTEGER 32 Fixed-size
PIXEL 32 Fixed-size
PIXMAP 32 Fixed-size
SPAN 32 Fixed-size
STRING 8 Zero
WINDOW 32 Fixed-size
It is expected that this table will grow over time.
TEXT Properties
In general,
the encoding for the characters in a text string property is specified
by its type.
It is highly desirable for there to be a simple, invertible mapping
between string property types and any character set names
embedded within font names in any font naming standard adopted by the
Consortium.
The atom TEXT is a polymorphic target.
Requesting conversion into TEXT will convert into whatever encoding
is convenient for the owner.
The encoding chosen will be indicated by the type of the property returned.
it will never be the returned type from a selection conversion request.
If the requestor wants the owner to return the contents of the selection
in a specific encoding,
it should request conversion into the name of that encoding.
In the table in ,
the word TEXT (in the Type column) is used to indicate one
of the registered encoding names.
The type would not actually be TEXT;
it would be STRING or some other ATOM naming the encoding chosen by the owner.
STRING as a type or a target specifies the ISO Latin-1 character set plus the
control characters TAB (octal 11) and NEWLINE (octal 12).
The spacing interpretation of TAB is context dependent.
Other ASCII control characters are explicitly not included in STRING
at the present time.
COMPOUND_TEXT as a type or a target specifies the Compound Text interchange
see the Compound Text Encoding.
There are some text objects where the source or intended user, as the
case may be, does not have a specific character set for the text, but
instead merely requires a zero-terminated sequence of bytes with no
no element of the selection mechanism may assume that
any byte value is forbidden or that any two differing sequences are
equivalent.
For these objects, the type C_STRING should be used.
An example of the need for C_STRING is to transmit the names of
many operating systems do not interpret filenames as having
a character set. For example, the same character string uses a
different sequence of bytes in ASCII and EBCDIC, and so most
operating systems see these as different filenames, and offer no
way to treat them as the same. Thus no character-set based
property type is suitable.
Type STRING, COMPOUND_TEXT, and C_STRING properties will consist of a list
of elements separate other encodings will need to
specify an appropriate list format.
INCR Properties
Requestors may receive a property of type INCR
in response to any target that results in selection data.
This indicates that the owner will send the actual data incrementally.
The contents of the INCR property will be an integer,
which represents a lower bound on the number of bytes of data in the selection.
The requestor and the selection owner transfer the data in the selection
in the following manner.
The selection requestor starts the transfer process by deleting
the (type==INCR) property forming the reply to the selection.
The selection owner then:
Appends the data in suitable-size chunks to the
same property on the same window as the selection reply
with a type corresponding to the actual type of the converted selection.
The size should be less than the maximum-request-size in the connection
handshake.
Waits between each append for a
PropertyNotify (state==Deleted)
event that shows that the requestor has read the data.
The reason for doing this is to limit the consumption of space in the server.
Waits (after the entire data has been transferred to the server) until a
PropertyNotify (state==Deleted)
event that shows that the data has been read by the requestor
and then writes zero-length data to the property.
The selection requestor:
Waits for the
SelectionNotify
Retrieving data using
GetProperty
with the delete argument
Waiting for a
PropertyNotify
with the state argument
NewValue .
Waits until the property named by the
PropertyNotify
event is zero-length.
Deletes the zero-length property.
The type of the converted selection is the type of the first partial property.
The remaining partial properties must have the same type.
DRAWABLE Properties
Requestors may receive properties of type PIXMAP, BITMAP, DRAWABLE, or WINDOW,
which contain an appropriate ID.
While information about these drawables is available from the server by means of
GetGeometry
the following items are not:
Foreground pixel
Background pixel
Colormap ID
In general,
requestors converting into targets whose returned type in the table
is one of the DRAWABLE types should expect to convert also
into the following targets (using the MULTIPLE mechanism):
FOREGROUND returns a PIXEL value.
BACKGROUND returns a PIXEL value.
COLORMAP returns a colormap ID.
SPAN Properties
Properties with type SPAN contain a list of cardinal-pairs
with the length of the cardinals determined by the format.
The first specifies the starting position,
and the second specifies the ending position plus one.
The base is zero.
If they are the same,
the span is zero-length and is before the specified position.
The units are implied by the target atom,
such as LINE_NUMBER or CHARACTER_POSITION.
Manager Selections
Certain clients, often called managers, take on responsibility
for managing shared resources.
A client that manages a shared
resource should take ownership of an appropriate selection,
named using the conventions described in sections
A client that manages multiple
shared resources (or groups of resources) should take
ownership of a selection for each one.
The manager may support conversion of various targets
for that selection.
Managers are encouraged to use this
technique as the primary means by which clients interact
with the managed resource.
Note that the conventions for
interacting with the window manager
as a result many interactions with the window manager use
other techniques.
Before a manager takes ownership of a manager selection, it
should use the
GetSelectionOwner
request to check whether the selection is already owned by another client,
and where appropriate, it should ask the user if the new manager should
replace the old one.
If so, it may then take ownership of the selection.
Managers should acquire the selection using a window created expressly for
this purpose.
Managers must conform to the rules for selection owners
described in sections
and , and they must also support the required
targets listed in .
If a manager loses ownership of a manager selection, this
means that a new manager is taking over its responsibilities.
The old manager must release all resources it has managed,
and must then destroy the window that owned the selection.
For example, a window manager losing ownership of WM_S2
must deselect from
SubstructureRedirect
on the root window of screen 2 before destroying the window that owned
When the new manager notices that the window owning the selection
has been destroyed, it knows that it can successfully proceed to
control the resource it is planning to manage.
If the old
manager does not destroy the window within a reasonable time,
the new manager should check with the user before destroying
the window itself or killing the old manager.
If a manager wants to give up, on its own, management of a shared
resource controlled by a selection, it must do so by releasing
the resources it is managing, and then by destroying the
window that owns the selection.
It should not first disown
the selection, since this introduces a race condition.
Clients who are interesting in knowing when the owner of a
manager selection is no longer managing the corresponding shared
resource should select for
StructureNotify
on the window owning the selection so they can be notified when the window
is destroyed.
Clients are warned that after doing a
GetSelectionOwner
and selecting for
StructureNotify ,
they should do a
GetSelectionOwner
again to ensure that the owner did not change after initially getting the
selection owner and before selecting for
StructureNotify .
Immediately after a manager successfully acquires ownership of a
manager selection, it should announce its arrival by sending a
ClientMessage
This event should be sent using the
protocol request with the following arguments:
Argument Value
destination: the root window of screen 0, or the root manager is managing a screen-specific resource
propagate: False
event-mask: StructureNotify
event: ClientMessage
type: MANAGER
format: 32
data[1]: manager selection atom
data[2]: the window owning the selection
data[3]: manager-selection-specific data
data[4]: manager-selection-specific data
Clients that wish to know when a specific manager has started should
select for
StructureNotify
on the appropriate root window, and should watch for the appropriate MANAGER
ClientMessage .}