DragonFly On-Line Manual Pages

XCB(1) DragonFly General Commands Manual XCB(1)

NAME
xcb - X Cut Buffers - Pigeon holes for your cut and paste selections.

SYNOPSIS
xcb [Xt option] [-l layout] [-n count] [-p|-s|-S list] [-r count]

DESCRIPTION
Xcb provides easy access to the cut buffers built into every X server.
It allows the buffers to be manipulated either via the command line, or
with the mouse in a point and click manner. The buffers can be used as
holding pens to store and retrieve arbitrary data fragments. Any
number of cut buffers may be created, so any number of different pieces
of data can be saved and recalled later. By default, 8 cut buffers are
created. The program is designed primarily for use with textual data.

Xcb has two modes of operation. Normally xcb provides an array of
windows on your display, one per cut buffer, tiled horizontally,
vertically, or in some user specified layout. Each window displays the
contents of its respective cut buffer. Data can be cut from and pasted
to the windows in a similar manner to xterm. The buffers can also be
rotated.

In task mode, xcb lets you access the cut buffers from the command
line. Cut buffers can be loaded from stdin, copied or concatenated to
stdout, loaded using the current PRIMARY selection, or rotated an
arbitrary number of positions. In this mode of operation, xcb performs
the requested task and then exits. It does not create any windows and
has no interaction with the mouse or keyboard.

OPTIONS
Xcb supports the full set of X Toolkit Intrinsics options, as well as
those listed below. Xcb options can appear in any order. The presence
of the -p, -r, -s or -S options causes xcb to execute in task mode,
described above.

-l layout
This option controls the geometry arrangement of xcb's
subwindows. It is the command line equivalent of the .layout
resource, described below.

-n count
Create count cut buffers. Count can be any integer greater than
zero. This option is the command line equivalent of the
.bufferCount resource, described below.

-u Use utf-8 instead of the current locale settings when executing
in task mode and doing I/O.

-V Print the xcb release version number and exit immediately.

-p list
Print the contents of the listed buffer(s) on stdout. The
buffered data is printed exactly as it is stored in the server.
Selecting two or more buffers has the effect of concatenating
the data on stdout. The cut buffers are numbered from 0...
onwards. The list can be either a single digit, a comma
separated list of digits, a range of the form m-n, or some
combination of lists and ranges. The buffers are printed in
listed order, so repeated numbers in the list can be used to
duplicate buffer contents.

-r count
Rotate the buffers by count positions. Count can be any
integer, positive or negative. This option may be used in
conjunction with the -n count option to rotate a specific number
of buffers. If the -n option is not used, xcb will rotate the
number of buffers given by the .bufferCount resource.

-s list
Store the data from stdin in the listed buffer(s). If the list
refers to two or more buffers, the input data is duplicated in
each buffer. Refer to the -p option for the definition of a
list.

-S list
Store the current PRIMARY selection data in the listed
buffer(s). The data is converted to a string representation.
If the list refers to two or more buffers, the PRIMARY selection
is duplicated in each buffer. Refer to the -p option for the
definition of a list. Under the -S option xcb waits for the
nominated cut buffer's contents to change before exiting. If no
change is detected within 3 seconds, xcb exits with a non-zero
return code.

WIDGETS and RESOURCES
The xcb widget hierarchy consists of a collection of custom buffer
widgets, one per cut buffer. In the Athena version of the program,
these buffer widgets are all contained within a single Athena form
widget. In the Motif version of the program, they are each enclosed by
Motif frame widgets, and the frame widgets are all contained within a
single Motif RowColumn widget.

The names of the buffer widgets are "buffer0", "buffer1", "buffer2",
.... etc., and their class name is "Buffer". Each buffer widget
supports all the standard core widget resources, plus the .foreground
and .fontSet resources.

Application wide resources are as follows:

.bufferCount (default value 8)
This is the number of buffer widgets to create.
Any number of widgets (greater than zero) can be created.

.layout (default value "h")
Only the first character of the resource value is significant.
This is the geometry arrangement to apply in the container widget.
The layout can be "h" (horizontal), "v" (vertical), or some
other value to disable the inbuilt geometry code and specify
the layout via your X resources. An example is provided in the
application default resources file.

EVENTS and TRANSLATIONS
Xcb's input semantics are coded into a Toolkit translation table. The
default bindings have been chosen to conform with the default
configuration of other cut and paste clients, such as xterm. The
bindings may be altered or overridden according to your needs. The
actions functions provided by xcb are:-

cut() causes the contents of the chosen cut buffer to become
the PRIMARY selection. The window contents, if any,
are highlighted, and can then be pasted into other
cut buffers or applications.

paste() causes the value of the PRIMARY selection to be
converted into text and pasted into the chosen cut
buffer, overwriting any previous buffer contents.
If no PRIMARY selection is present, xcb pastes
the contents of cut buffer zero into the chosen buffer.

clear() clears the chosen cut buffer.

rotate(NN) rotates the cut buffers by NN positions. NN may
be any positive or negative number.

refresh() causes the cut buffer window to be cleared and redrawn.

selreq() this action function handles paste requests
from other clients, or other xcb windows.
It should always be bound to SelectionRequest events.

selclear() this action function responds to the loss of
ownership of the PRIMARY selection property.
It should always be bound to SelectionClear events.

quit() causes xcb to terminate.

The default bindings are as follows:-

<Btn1Down>: cut() \n\
Shift <Btn2Down>: clear() \n\
<Btn2Down>: paste() \n\
Shift <Btn3Down>: rotate(-1) \n\
<Btn3Down>: rotate(1) \n\
<Key>Left: rotate(-1) \n\
<Key>Right: rotate(1) \n\
<Key>Up: rotate(-1) \n\
<Key>Down: rotate(1) \n\
<Key>q: quit() \n\
<SelReq>: selreq() \n\
<SelClr>: selclear()

EXAMPLES
The following are some examples of xcb task mode usage:-

xcb -s 0-7 < /dev/null
This clears the first 8 cut buffers in your server.

echo "G'day." | xcb -display bigears:0.0 -s 1,3,5,7
This loads the string "G'day." into four of the cut buffers on the
display "bigears".

xsendevent -win buffer5 '<Btn1Down>'
This uses the program xsendevent to send a synthetic mouse click event
to an xcb subwindow, thereby making that window the owner of the
PRIMARY selection.

ls `xcb -p 2,3`
This produces a listing of all the files named in cut buffers 2 and 3.

xcb -p 0-7 | xcb -s 0
This concatenates the values in the first 8 cut buffers, and places the
result back in cut buffer zero.

xcb -S 0 && xcb -p 0
The first command copies the current PRIMARY selection into the first
cut buffer. If the copy succeeds, then the second command prints that
data on stdout.

for i in 0 1 2 3 4 5 6 7
do
xcb -p $i > $HOME/.xcb/$i
done
for i in 0 1 2 3 4 5 6 7
do
xcb -s $i < $HOME/.xcb/$i
done
This first loop saves the contents of each of the cut buffers in a
separate file under your home directory. The second loop restores the
cut buffer contents from those files. When placed in your .logout and
.login scripts respectively, the commands are a simple method of
preserving your cut buffers across login sessions.

function g {
echo "$1\\c" | xcb -s 7
grep "$@"
}
function vg {
vi +/`xcb -p 7` "$@"
}
These two shell functions exemplify a simple mechanism for saving and
reusing regular expressions. The first function saves the regex used
for grep-ing into cut buffer 7. The second function reuses the most
recent grep regex as a search command in vi. There is considerable
scope for expanding and improving these ideas.

SEE ALSO
xterm(1), xcutsel(1), xclipboard(1), xprop(1)
Athena Widget Set - C Language Interface
Motif Programmers Reference Guide

AUTHORS
Current Maintainer (I18n version)
Marc Lehmann
E-mail: pcg@goof.com

Original Author
Farrell McKay
E-mail: Farrell.McKay@mpx.com.au

XView modifications provided by Danny Vanderryn
E-mail: dvanderr@us.oracle.com

Permission to use, copy, modify, and distribute this software and its
documentation for any purpose and without fee is hereby granted,
provided that the above copyright notice appears in all copies and that
both that copyright notice and this permission notice appear in
supporting documentation. This software is provided "as is" without
express or implied warranty.

BUGS :-)
Xlib's underlying protocol for moving selection data between client and
server can sometimes be slow, depending on the amount of data involved.
Do not expect fast performance if your selections are big or you want
to store big files in your cut buffers! ("big" means, say, over 10k
bytes - but your mileage may vary).

X Version 11 Oct 6 1994 XCB(1)
xcb_change_gc(3) XCB Requests xcb_change_gc(3)

NAME
xcb_change_gc - change graphics context components

SYNOPSIS
#include <xcb/xproto.h>

Request function
xcb_void_cookie_t xcb_change_gc(xcb_connection_t *conn,
xcb_gcontext_t gc, uint32_t value_mask, const void *value_list);

REQUEST ARGUMENTS
conn The XCB connection to X11.

gc The graphics context to change.

value_mask
One of the following values:

XCB_GC_FUNCTION
TODO: Refer to GX

XCB_GC_PLANE_MASK
In graphics operations, given a source and
destination pixel, the result is computed bitwise
on corresponding bits of the pixels; that is, a
Boolean operation is performed in each bit plane.
The plane-mask restricts the operation to a subset
of planes, so the result is:

((src FUNC dst) AND plane-mask) OR (dst AND
(NOT plane-mask))

XCB_GC_FOREGROUND
Foreground colorpixel.

XCB_GC_BACKGROUND
Background colorpixel.

XCB_GC_LINE_WIDTH
The line-width is measured in pixels and can be
greater than or equal to one, a wide line, or the
special value zero, a thin line.

XCB_GC_LINE_STYLE
The line-style defines which sections of a line are
drawn: Solid The full path of the
line is drawn. DoubleDash The full path
of the line is drawn, but the even dashes are
filled differently
than the odd dashes (see fill-
style), with Butt cap-style used where even and
odd dashes meet. OnOffDash
Only the even dashes are drawn, and cap-style
applies to all internal ends of
the individual dashes (except
NotLast is treated as Butt).

XCB_GC_CAP_STYLE
The cap-style defines how the endpoints of a path
are drawn: NotLast The result is equivalent to
Butt, except that for a line-width of zero the
final
endpoint is not drawn. Butt The
result is square at the endpoint (perpendicular to
the slope of the line)
with no projection beyond. Round
The result is a circular arc with its diameter
equal to the line-width, centered
on the endpoint; it is equivalent to
Butt for line-width zero. Projecting The result is
square at the end, but the path continues beyond
the endpoint for
a distance equal to half the line-width;
it is equivalent to Butt for line-width
zero.

XCB_GC_JOIN_STYLE
The join-style defines how corners are drawn for
wide lines: Miter The outer edges of
the two lines extend to meet at an angle. However,
if the
angle is less than 11 degrees,
a Bevel join-style is used instead. Round
The result is a circular arc with a diameter equal
to the line-width, centered
on the joinpoint. Bevel
The result is Butt endpoint styles, and then the
triangular notch is filled.

XCB_GC_FILL_STYLE
The fill-style defines the contents of the source
for line, text, and fill requests. For all text and
fill requests (for example, PolyText8, PolyText16,
PolyFillRectangle, FillPoly, and PolyFillArc) as
well as for line requests with line-style Solid,
(for example, PolyLine, PolySegment, PolyRectangle,
PolyArc) and for the even dashes for line requests
with line-style OnOffDash or DoubleDash: Solid
Foreground Tiled Tile
OpaqueStippled A tile with the same
width and height as stipple but with background
everywhere stipple has a
zero and with foreground everywhere stipple
has a one Stippled
Foreground masked by stipple For the odd dashes for
line requests with line-style DoubleDash: Solid
Background Tiled Same as for
even dashes OpaqueStippled Same as for
even dashes Stippled Background
masked by stipple

XCB_GC_FILL_RULE

XCB_GC_TILE
The tile/stipple represents an infinite two-
dimensional plane with the tile/stipple replicated
in all dimensions. When that plane is superimposed
on the drawable for use in a graphics operation,
the upper-left corner of some instance of the
tile/stipple is at the coordinates within the
drawable specified by the tile/stipple origin. The
tile/stipple and clip origins are interpreted
relative to the origin of whatever destination
drawable is specified in a graphics request. The
tile pixmap must have the same root and depth as
the gcontext (or a Match error results). The
stipple pixmap must have depth one and must have
the same root as the gcontext (or a Match error
results). For fill-style Stippled (but not fill-
style OpaqueStippled), the stipple pattern is tiled
in a single plane and acts as an additional clip
mask to be ANDed with the clip-mask. Any size
pixmap can be used for tiling or stippling,
although some sizes may be faster to use than
others.

XCB_GC_STIPPLE
The tile/stipple represents an infinite two-
dimensional plane with the tile/stipple replicated
in all dimensions. When that plane is superimposed
on the drawable for use in a graphics operation,
the upper-left corner of some instance of the
tile/stipple is at the coordinates within the
drawable specified by the tile/stipple origin. The
tile/stipple and clip origins are interpreted
relative to the origin of whatever destination
drawable is specified in a graphics request. The
tile pixmap must have the same root and depth as
the gcontext (or a Match error results). The
stipple pixmap must have depth one and must have
the same root as the gcontext (or a Match error
results). For fill-style Stippled (but not fill-
style OpaqueStippled), the stipple pattern is tiled
in a single plane and acts as an additional clip
mask to be ANDed with the clip-mask. Any size
pixmap can be used for tiling or stippling,
although some sizes may be faster to use than
others.

XCB_GC_TILE_STIPPLE_ORIGIN_X
TODO

XCB_GC_TILE_STIPPLE_ORIGIN_Y
TODO

XCB_GC_FONT
Which font to use for the ImageText8 and
ImageText16 requests.

XCB_GC_SUBWINDOW_MODE
For ClipByChildren, both source and destination
windows are additionally clipped by all viewable
InputOutput children. For IncludeInferiors, neither
source nor destination window is clipped by
inferiors. This will result in including subwindow
contents in the source and drawing through
subwindow boundaries of the destination. The use of
IncludeInferiors with a source or destination
window of one depth with mapped inferiors of
differing depth is not illegal, but the semantics
is undefined by the core protocol.

XCB_GC_GRAPHICS_EXPOSURES
Whether ExposureEvents should be generated (1) or
not (0).

The default is 1.

XCB_GC_CLIP_ORIGIN_X
TODO

XCB_GC_CLIP_ORIGIN_Y
TODO

XCB_GC_CLIP_MASK
The clip-mask restricts writes to the destination
drawable. Only pixels where the clip-mask has bits
set to 1 are drawn. Pixels are not drawn outside
the area covered by the clip-mask or where the
clip-mask has bits set to 0. The clip-mask affects
all graphics requests, but it does not clip
sources. The clip-mask origin is interpreted
relative to the origin of whatever destination
drawable is specified in a graphics request. If a
pixmap is specified as the clip-mask, it must have
depth 1 and have the same root as the gcontext (or
a Match error results). If clip-mask is None, then
pixels are always drawn, regardless of the clip
origin. The clip-mask can also be set with the
SetClipRectangles request.

XCB_GC_DASH_OFFSET
TODO

XCB_GC_DASH_LIST
TODO

XCB_GC_ARC_MODE
TODO

value_list
Values for each of the components specified in the bitmask
value_mask. The order has to correspond to the order of
possible value_mask bits. See the example.

DESCRIPTION
Changes the components specified by value_mask for the specified
graphics context.

RETURN VALUE
Returns an xcb_void_cookie_t. Errors (if any) have to be handled in the
event loop.

If you want to handle errors directly with xcb_request_check instead,
use xcb_change_gc_checked. See xcb-requests(3) for details.

ERRORS
xcb_alloc_error_t
The X server could not allocate the requested resources (no
memory?).

xcb_font_error_t
TODO: reasons?

xcb_g_context_error_t
TODO: reasons?

xcb_match_error_t
TODO: reasons?

xcb_pixmap_error_t
TODO: reasons?

xcb_value_error_t
TODO: reasons?

EXAMPLE

/*
* Changes the foreground color component of the specified graphics context.
*
*/
void my_example(xcb_connection_t *conn, xcb_gcontext_t gc, uint32_t fg, uint32_t bg) {
/* C99 allows us to use a compact way of changing a single component: */
xcb_change_gc(conn, gc, XCB_GC_FOREGROUND, (uint32_t[]){ fg });

/* The more explicit way. Beware that the order of values is important! */
uint32_t mask = 0;
mask |= XCB_GC_FOREGROUND;
mask |= XCB_GC_BACKGROUND;

uint32_t values[] = {
fg,
bg
};
xcb_change_gc(conn, gc, mask, values);
xcb_flush(conn);
}

SEE ALSO
xcb-requests(3), xcb-examples(3)

AUTHOR
Generated from xproto.xml. Contact xcb@lists.freedesktop.org for
corrections and improvements.

X Version 11 libxcb 1.15 xcb_change_gc(3)

DragonFly On-Line Manual Pages

NAME

SYNOPSIS

DESCRIPTION

OPTIONS

EXAMPLES

SEE ALSO

AUTHORS

COPYRIGHT

NAME

SYNOPSIS

REQUEST ARGUMENTS

DESCRIPTION

RETURN VALUE

ERRORS

EXAMPLE

SEE ALSO

AUTHOR