Limitations and criticism

The Unix-Haters Handbook (1994) devoted a full chapter to the problems of X. Why X Is Not Our Ideal Window System (1990) by Gajewska, Manasse and McCormack detailed problems in the protocol with recommendations for improvement.

User interface issuesedit

The lack of design guidelines in X has resulted in several vastly different interfaces, and in applications that have not always worked well together. The Inter-Client Communication Conventions Manual (ICCCM), a specification for client interoperability, has a reputation for being difficult to implement correctly. Further standards efforts such as Motif and CDE did not alleviate problems. This has frustrated users and programmers. Graphics programmers now generally address consistency of application look and feel and communication by coding to a specific desktop environment or to a specific widget toolkit, which also avoids having to deal directly with the ICCCM.

X also lacks native support for user-defined stored procedures on the X server, in the manner of NeWS – there is no Turing-complete scripting facility. Various desktop environments may thus offer their own (usually mutually incompatible) facilities.

Computer accessibility related issuesedit

Systems built upon X may have accessibility issues that make utilization of a computer difficult for disabled users, including right click, double click, middle click, mouse-over, and focus stealing. Some X11 clients deal with accessibility issues better than others, so persons with accessibility problems are not locked out of using X11. However, there is no accessibility standard or accessibility guidelines for X11. Within the X11 standards process there is no working group on accessibility, however, accessibility needs are being addressed by software projects to provide these features on top of X.

The Orca project adds accessibility support to the X Window System, including implementing an API (AT-SPI). This is coupled with GNOME's ATK to allow for accessibility features to be implemented in X programs using the GNOME/GTK APIs. KDE provides a different set of accessibility software, including a text-to-speech converter and a screen magnifier. The other major desktops (LXDE, Xfce and Enlightenment) attempt to be compatible with ATK.


An X client cannot generally be detached from one server and reattached to another unless its code specifically provides for it (Emacs is one of the few common programs with this ability). As such, moving an entire session from one X server to another is generally not possible. However, approaches like Virtual Network Computing (VNC), NX and Xpra allow a virtual session to be reached from different X servers (in a manner similar to GNU Screen in relation to terminals), and other applications and toolkits provide related facilities. Workarounds like x11vnc (VNC :0 viewers), Xpra's shadow mode and NX's nxagent shadow mode also exist to make the current X-server screen available. This ability allows the user interface (mouse, keyboard, monitor) of a running application to be switched from one location to another without stopping and restarting the application.

Network traffic between an X server and remote X clients is not encrypted by default. An attacker with a packet sniffer can intercept it, making it possible to view anything displayed to or sent from the user's screen. The most common way to encrypt X traffic is to establish a Secure Shell (SSH) tunnel for communication.

Like all thin clients, when using X across a network, bandwidth limitations can impede the use of bitmap-intensive applications that require rapidly updating large portions of the screen with low latency, such as 3D animation or photo editing. Even a relatively small uncompressed 640x480x24 bit 30 fps video stream (~211 Mbit/s) can easily outstrip the bandwidth of a 100 Mbit/s network for a single client. In contrast, modern versions of X generally have extensions such as MESA allowing local display of a local program's graphics to be optimized to bypass the network model and directly control the video card, for use of full-screen video, rendered 3D applications, and other such applications.

Client–server separationedit

X's design requires the clients and server to operate separately, and device independence and the separation of client and server incur overhead. Most of the overhead comes from network round-trip delay time between client and server (latency) rather than from the protocol itself: the best solutions to performance issues depend on efficient application design. A common criticism of X is that its network features result in excessive complexity and decreased performance if only used locally.

Modern X implementations use Unix domain sockets for efficient connections on the same host. Additionally shared memory (via the MIT-SHM extension) can be employed for faster client–server communication. However, the programmer must still explicitly activate and use the shared memory extension. It is also necessary to provide fallback paths in order to stay compatible with older implementations, and in order to communicate with non-local X servers.


Popular posts from this blog

39)All-woman BSF bikers create story with Republic Day iniciación; Twitterati beam with take great pride in