X Windows

From Jonathan Gardner's Tech Wiki
(Redirected from X Window System)
Jump to: navigation, search

Introduction

X Windows is a software system and technology for handling GUIs.

Core Philosophy

The core philosophy of X Windows is separating the apps from the presentation. The applications communicate with an X server. The X server is bound to hardware and renders what the applications want it to render. The X server sends events and such to the applications to let them know when users click or when windows are moved around.

At the heart of the client-server relationship is the X protocol. This is how the server and client communicate. The X protocol has been shown to be resilient, especially the latest incarnation (X11) that has been in use since 1987.

The X protocol can be run across network connections. However, the protocol itself has problems when latency is high or bandwidth is low, so typically networked computers only run over local networks.

NeatX is a technology that allows you to run X windows over networks where latency and bandwidth are not good enough for X windows itself. It works by acting as an X server, compressing and batching messages between the NeatX client (which does the actual rendering) and the application.

Terminology

  • X Windows or X Window System: The system altogether. Really, the description of how the system should work.
  • X server: The X server is the component that actually draws the graphics and accepts input. On a desktop computer, there is only one X server running, unless you have separate sessions.
  • X client: The X client is the component that is the application. Rather than drawing directly to the screen or accepting input directly from the input devices, it communicates with the X server using the X protocol.
  • X protocol: The X protocol is the message passing protocol that X clients and X servers use to communicate with each other. The current version is X11, which is an extensible protocol that allows for additional message types and schemas.
  • Screen: A screen is a device on which the X server can draw things. There may be more than one screen connected to a single X server. Different X servers may share the same screen if the kernel supports virtual devices.
  • Input device: An input device is a device that provides input from the user. Its signals are sent to the X server, which translates them to messages sent to the appropriate X client.
  • X Window Manager: A window manager is an X client who handles the management of windows within the the X server. It will draw borders and buttons to move, resize, close, hide, or shutter the X clients. There are a variety of window managers out there.
  • Desktop Environment: A desktop environment is a combination of applications and a window manager that gives a consistent feel to the user for all X clients. These include, but are not limited to: KDE, Gnome, XFCE, and more. See http://xwinman.org/ for several.
  • Toolkit: X only provides graphical primitives and doesn't provide advanced widgets such as toolbars, scrollbars, and more. There are several toolkits that provide these things on top of X, such as Qt and GTK.
  • X session: An X session represents a user's session with the X server. Applications must have access to the session or they cannot communicate with the X server. SSH allows you to forward your X session so that when you login to a remote computer and run an application there, it will interact with your local X server over SSH.
  • X terminal: The X terminal is a terminal program, meaning, a program that allows you to connect with a command-line interface to the computer. (In the old days, terminals were the screen-keyboard combinations that sat between users and their computers.) Alternative implementations exist such as Konsole for KDE.
  • Input Method: The X system allows you to plug in an input method system. This will translate key strokes to something like Chinese, Japanese, Korean, etc...

Compared with Windows

In Windows, the graphical elements of the operating system are part of the same system. Applications communicate through the kernel with other applications, the input devices, and the screen. Microsoft provides an ABI and a message passing model which greatly simplifies development.

Implementations

It used to be that XFree86 was the primary implentation of the X protocol. Nowadays, X.org has become the preferred implementation. This was because of disagreement over how to treat new technology. The people who formed X.org were frustrated at the snail's pace of development in XFree86 and so forked the code.

Running X on Windows

There are several implementations of the X protocol on windows. You can run X session from your windows session, and thus run linux apps from a linux host on windows.

Future

The future remains bright. Alternatives to X are shallow in comparison. Apple has its own proprietary clone of X with all the features Apple wants, but it is based on the same underlying principles.

Audio has always been a sore spot with X since the protocol isn't specified to allow it. Typically, applications which want to use audio have to simultaneously connect to some kind of audio server or even write directly to the audio device. However, it is possible that the X protocol can be extended to include audio, once a standard has been agreed to.

X has lagged, particularly in the past decades, to other operating systems with regards to hardware support. However, there are several projects underway to maximize the efficiency of X on those hardware platforms.

X doesn't allow you to move and X server from one machine to another. However, technology like NeatX may solve that problem, allowing you to take your session from one computer to another without any changes to the clients.

X protocol tends to be serial in nature. That is, if you give two inputs, it waits for the response from the first input before sending the next one. X would benefit greatly if it used a more asynchronous model.

X has a problem with frame buffers. This manifests as shearing or blinking when moving things around. This, however, can be solved with a better X implementation that adheres to more modern hardware standards and an asynchronous protocol.

The X protocol of the future may be completely different than the X protocol today. However, the concept is sound, and will be here to stay, especially as we move back to thin client computing.

See Also

  • NeatX: A great way to run sessions over the internet.