DragonFly On-Line Manual Pages

Search: Section:  

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


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


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


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.


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()


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.


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


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


Copyright (C) 1992,1993,1994 by Farrell McKay. 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_window_attributes(3) XCB Requests xcb_change_window_attributes(3)


xcb_change_window_attributes - change window attributes


#include <xcb/xproto.h> Request function xcb_void_cookie_t xcb_change_window_attributes(xcb_connection_t *conn, xcb_window_t window, uint32_t value_mask, const void *value_list);


conn The XCB connection to X11. window The window to change. value_mask One of the following values: XCB_CW_BACK_PIXMAP Overrides the default background-pixmap. The background pixmap and window must have the same root and same depth. Any size pixmap can be used, although some sizes may be faster than others. If XCB_BACK_PIXMAP_NONE is specified, the window has no defined background. The server may fill the contents with the previous screen contents or with contents of its own choosing. If XCB_BACK_PIXMAP_PARENT_RELATIVE is specified, the parent's background is used, but the window must have the same depth as the parent (or a Match error results). The parent's background is tracked, and the current version is used each time the window background is required. XCB_CW_BACK_PIXEL Overrides BackPixmap. A pixmap of undefined size filled with the specified background pixel is used for the background. Range-checking is not performed, the background pixel is truncated to the appropriate number of bits. XCB_CW_BORDER_PIXMAP Overrides the default border-pixmap. The border pixmap and window must have the same root and the same depth. Any size pixmap can be used, although some sizes may be faster than others. The special value XCB_COPY_FROM_PARENT means the parent's border pixmap is copied (subsequent changes to the parent's border attribute do not affect the child), but the window must have the same depth as the parent. XCB_CW_BORDER_PIXEL Overrides BorderPixmap. A pixmap of undefined size filled with the specified border pixel is used for the border. Range checking is not performed on the border-pixel value, it is truncated to the appropriate number of bits. XCB_CW_BIT_GRAVITY Defines which region of the window should be retained if the window is resized. XCB_CW_WIN_GRAVITY Defines how the window should be repositioned if the parent is resized (see ConfigureWindow). XCB_CW_BACKING_STORE A backing-store of WhenMapped advises the server that maintaining contents of obscured regions when the window is mapped would be beneficial. A backing-store of Always advises the server that maintaining contents even when the window is unmapped would be beneficial. In this case, the server may generate an exposure event when the window is created. A value of NotUseful advises the server that maintaining contents is unnecessary, although a server may still choose to maintain contents while the window is mapped. Note that if the server maintains contents, then the server should maintain complete contents not just the region within the parent boundaries, even if the window is larger than its parent. While the server maintains contents, exposure events will not normally be generated, but the server may stop maintaining contents at any time. XCB_CW_BACKING_PLANES The backing-planes indicates (with bits set to 1) which bit planes of the window hold dynamic data that must be preserved in backing-stores and during save-unders. XCB_CW_BACKING_PIXEL The backing-pixel specifies what value to use in planes not covered by backing-planes. The server is free to save only the specified bit planes in the backing-store or save-under and regenerate the remaining planes with the specified pixel value. Any bits beyond the specified depth of the window in these values are simply ignored. XCB_CW_OVERRIDE_REDIRECT The override-redirect specifies whether map and configure requests on this window should override a SubstructureRedirect on the parent, typically to inform a window manager not to tamper with the window. XCB_CW_SAVE_UNDER If 1, the server is advised that when this window is mapped, saving the contents of windows it obscures would be beneficial. XCB_CW_EVENT_MASK The event-mask defines which events the client is interested in for this window (or for some event types, inferiors of the window). XCB_CW_DONT_PROPAGATE The do-not-propagate-mask defines which events should not be propagated to ancestor windows when no client has the event type selected in this window. XCB_CW_COLORMAP The colormap specifies the colormap that best reflects the true colors of the window. Servers capable of supporting multiple hardware colormaps may use this information, and window man- agers may use it for InstallColormap requests. The colormap must have the same visual type and root as the window (or a Match error results). If CopyFromParent is specified, the parent's colormap is copied (subsequent changes to the parent's colormap attribute do not affect the child). However, the window must have the same visual type as the parent (or a Match error results), and the parent must not have a colormap of None (or a Match error results). For an explanation of None, see FreeColormap request. The colormap is copied by sharing the colormap object between the child and the parent, not by making a complete copy of the colormap contents. XCB_CW_CURSOR If a cursor is specified, it will be used whenever the pointer is in the window. If None is speci- fied, the parent's cursor will be used when the pointer is in the window, and any change in the parent's cursor will cause an immediate change in the displayed cursor. value_list Values for each of the attributes specified in the bitmask value_mask. The order has to correspond to the order of possible value_mask bits. See the example.


Changes the attributes specified by value_mask for the specified window.


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_window_attributes_checked. See xcb-requests(3) for details.


xcb_access_error_t TODO: reasons? xcb_colormap_error_t TODO: reasons? xcb_cursor_error_t TODO: reasons? xcb_match_error_t TODO: reasons? xcb_pixmap_error_t TODO: reasons? xcb_value_error_t TODO: reasons? xcb_window_error_t The specified window does not exist.




Generated from xproto.xml. Contact xcb@lists.freedesktop.org for corrections and improvements. X Version 11 libxcb 1.15 xcb_change_window_attributes(3)

Search: Section: