X Window System protocols and architecture

The server answers by sending back a packet stating the acceptance or refusal of the connection, or with a request for a further authentication.

In particular, xprop -root shows the properties of the root window, which include the X resources (parameters of programs).

Whenever an area of destroyed content is made visible, the server generates an Expose event to notify the client that a part of the window has to be drawn.

Other events can serve to notify clients of keyboard or mouse input, of the creation of new windows, etc.

The way the X Window System handles colors can sometimes confuse users, and historically several different modes have been supported.

In particular, most clients use libraries such as Xaw, Motif, GTK+, or Qt which in turn use Xlib for interacting with the server.

Qt switched from Xlib to XCB with the 5.0 release, but client programs were almost entirely unaffected by this change.

The Inter-Client Communication Conventions Manual specifies the protocol for the exchange of data via selections and the interaction of applications with the window manager.

Some have considered this specification difficult and confusing;[3][4] consistency of application look and feel and communication is typically addressed by programming to a given desktop environment.

The X Window core protocol includes some types of requests and events that are specific to selection exchange, but the transfer is mainly done using the general client-to-client event sending and window properties, which are not specific to selection transfer.

Users can transfer data of different types between clients: it is usually text, but can also be a pixmap, a number, a list of objects, etc.

Cut buffers, by contrast, provide a passive mechanism: when the user selects some text, its content is transferred to a cut buffer, where it remains even if the application handling the window terminates and the window is destroyed.

This allows, for example, a user to move or resize the window by clicking and dragging on the border or on the title bar.

The window manager also handles icons and related visual elements of the graphical user interface.

For this to work, the session manager program stores the names of the running applications at logout and starts them again at login.

The program known as the X display manager shows the graphical login prompt in the X Window System.

The local servers are started by the display manager, which then connects to them to present the user the login screen.

In this situation, the display manager works like a graphical telnet server: an X server can connect to the display manager, which starts a session; the applications which utilize this session run on the same computer of the display manager but have input and output on the computer where the X server runs (which may be the computer in front of the user or a remote one).

The X Window System ships with XDM as the basic supplied display manager.

Other display managers include GDM (GNOME), KDM/SDDM (KDE), WDM (using the WINGs widget set used in Window Maker) and entrance (using the architecture used in Enlightenment v.17).

OLIT and XView function as the base toolkits for Sun's legacy OpenWindows desktop environment.

(Solaris 10 includes both CDE and GNOME, with the latter the preferred desktop environment as of 2010[update].)

Toolkits developed more recently include Qt (1991- , used by KDE), GTK+ (1997- , used by GNOME), wxWidgets (1992- ), FLTK (1998- ), FOX (1997- ) and fpGUI (2005-current).

[5] It is a long-term goal of the XCB project to automate generating both the client and server sides of extensions from XML protocol descriptions.

The following table provides a partial catalog of extensions that have been developed, sorted roughly by recency of introduction:

The X Window System logo
In this example, the X server takes input from a keyboard and mouse and displays to a screen. A web browser and a terminal emulator run on the user's workstation, and a terminal emulator runs on a remote server but under the control of the user's machine. Note that the remote application runs just as it would locally.
A possible placement of some windows: 1 is the root window, which covers the whole screen; 2 and 3 are top-level windows; 4 and 5 are subwindows of 2. The parts of window that are outside its parent are not visible.