Jump to content

X Window Programming/Xlib

From Wikibooks, open books for an open world
  1. Library Conventions
  2. Standard Headers
  3. Types and Values

Xlib is an X Window System protocol client library written in the C programming language. It contains functions for interacting with an X server. These functions allow programmers to write programs without knowing the details of the protocol. Few applications use Xlib directly; rather, they employ other libraries that use Xlib functions to provide widget toolkits:

Xlib and other libraries using it

Xlib appeared around 1985, and is currently used in GUIs for many Unix-like operating systems.

The XCB library is an attempt to replace Xlib.

Data types

[edit | edit source]

The main types of data in Xlib are the Display structure and the types of the identifiers.

Informally, a display is a physical or virtual device where graphical operations are done. The Display structure of the Xlib library contains information about the display, but more importantly it contains information relative to the channel between the client and the server. For example, in a Unix-like operating system, the Display structure contains the file handle of the socket of this channel (this can be retrieved using the ConnectionNumber macro.) Most Xlib functions have a Display structure as an argument because they either operate on the channel or are relative to a specific channel. In particular, all Xlib functions that interact with the server need this structure for accessing the channel. Some other functions need this structure, even if they operate locally, because they operate on data relative to a specific channel. Operations of this kind include for example operations on the event queue, which is described below.

Windows, colormaps, etc, are managed by the server. Thus, all their data are stored in the server, and the client cannot directly modify or operate on an object. Instead, the client submits requests to the server, each request specifying an operation and an object's identifier.

The types Window, Pixmap, Font, Colormap, etc, are all identifiers, which are 32-bit integers (just as in the X11 protocol itself). A client “creates” a window by asking the server to create a window. This is done via a call to an Xlib function that returns an identifier (a number) for the window. This identifier can then be used by the client to request further operations on that window.

The identifiers are unique to the server. Most of them can be used by different applications to refer to the same objects. For example, two applications connecting to the same server would use the same identifier to refer to the same window. These two applications use separate channels, and therefore have two different Display structures; however, when they request operations on the same identifier, these operations will be done on the same object.

Protocol and events

[edit | edit source]

The Xlib functions that send requests to the server usually do not send these requests immediately but store them in a buffer, called the output buffer. The term output in this case refers to the output from the client that is directed to the server: the output buffer can contain all kinds of requests to the server, not only those having a visible effect on the screen. The output buffer is guaranteed to be flushed (i.e., all requests done so far are sent to the server) after a call to the functions XSync or XFlush, after a call to a function that returns a value from the server (these functions block until the answer is received), and in some other conditions.

Xlib stores the received events in a queue. The client application can inspect and retrieve events from the queue. While the X server sends events asynchronously, applications using the Xlib library are required to explicitly call Xlib functions for accessing the events in the queue. Some of these functions may block; in this case, they also flush the output buffer.

Errors are instead received and treated asynchronously: the application can provide an error handler that will be called whenever an error message from the server is received.

The content of a window is not guaranteed to be preserved if the window of one of its parts are made not visible. In this case, the application is sent an Expose event when the window of one part of it is made visible again. The application is then supposed to draw the window content again.

Functions

[edit | edit source]

The functions in the Xlib library can be grouped in:

  1. operations on the connection (XOpenDisplay, XCloseDisplay, ...);
  2. requests to the server, including requests for operations (XCreateWindow, XCreateGC,...) and requests for information (XGetWindowProperty, ...); and
  3. operations that are local to the client: operations on the event queue (XNextEvent, XPeekEvent, ...) and other operations on local data (XLookupKeysym, XParseGeometry, XSetRegion, XCreateImage, XSaveContext, ...)

Example

[edit | edit source]

The following program creates a window with a little black square in it and exits on a keypress.

#include <stdio.h>
#include <stdlib.h>

#include <X11/Xlib.h>

enum {
        RECT_X = 20,
        RECT_Y = 20,
        RECT_WIDTH = 10,
        RECT_HEIGHT = 10,

        WIN_X = 10,
        WIN_Y = 10,
        WIN_WIDTH = 100,
        WIN_HEIGHT = 100,
        WIN_BORDER = 1
};

int main() {
        Display *display;
        Window window;
        XEvent event;
        int screen;

        /* open connection with the server */
        display = XOpenDisplay(NULL);
        if (display == NULL) {
                fprintf(stderr, "Cannot open display\n");
                exit(1);
        }

        screen = DefaultScreen(display);

        /* create window */
        window = XCreateSimpleWindow(display, RootWindow(display, screen), WIN_X, WIN_Y, WIN_WIDTH, WIN_HEIGHT,
                WIN_BORDER, BlackPixel(display, screen), WhitePixel(display, screen));

        /* process window close event through event handler so XNextEvent does not fail */
        Atom del_window = XInternAtom(display, "WM_DELETE_WINDOW", 0);
        XSetWMProtocols(display, window, &del_window, 1);

        /* select kind of events we are interested in */
        XSelectInput(display, window, ExposureMask | KeyPressMask);

        /* display the window */
        XMapWindow(display, window);

        /* event loop */
        while (1) {
                XNextEvent(display, &event);

                switch (event.type) {
                        case KeyPress:
                                /* FALLTHROUGH */
                        case ClientMessage:
                                goto breakout;
                        case Expose:
                                /* draw the window */
                                XFillRectangle(display, window, DefaultGC(display, screen), RECT_X, RECT_Y, RECT_WIDTH, RECT_HEIGHT);

                        /* NO DEFAULT */
                }
        }
breakout:

        /* destroy window */
        XDestroyWindow(display, window);

        /* close connection to server */
        XCloseDisplay(display);

        return 0;
}

The client creates a connection with the server by calling XOpenDisplay. It then requests the creation of a window with XCreateSimpleWindow. A separate call to XMapWindow is necessary for mapping the window, that is, for making it visible on the screen.

The square is drawn by calling XFillRectangle. This operation can only be performed after the window is created. However, performing it once may not be enough. Indeed, the content of the window is not always guaranteed to be preserved. For example, if the window is covered and then uncovered again, its content might require that it be drawn again. The program is informed that the window or a part of it has to be drawn by the reception of an Expose event.

The drawing of the window content is therefore made inside the loop handling the events. Before entering this loop, the events the application is interested in are selected, in this case with XSelectInput. The event loop waits for an incoming event: if this event is a key press, the application exits; if it is an expose event, the window content is drawn. The function XNextEvent blocks and flushes the output buffer if there is no event in the queue.

Going Further

[edit | edit source]

manual of the Xlib

Other libraries

[edit | edit source]

Xlib does not provide support for buttons, menus, scrollbar, etc. Such widgets are provided by other libraries, which in turn use Xlib. There are two kinds of such libraries:

  • libraries built atop of the Intrinsics library (Xt), which provides support for widgets but does not provide any particular widget; specific widgets are provided by widget set libraries that use Xt, such as Xaw and Motif;
  • libraries that provide widget sets using Xlib directly, without the Xt library, such as GTK+, Qt (X11 version), and FLTK (X11 version).

Applications using any of these widget libraries typically specify the content of the window before entering the main loop and do not need to explicitly handle Expose events and redraw the window content.

The XCB library is an alternative to Xlib. Its two main aims are: reduction in library size and direct access to the X11 protocol. A modification of Xlib has been produced to use XCB as a low-level layer.