The X Window System is a windowing system first developed in MIT by the Athena group. It is an advanced windowing system with some intricacies and many features.
There are two main parts to an X window system. The first is the X window server. This is the software which runs directly on the graphics hardware and provides the graphical services. The second component is the X client. An X client is any program which connects to the X server in order to request graphical services, such as drawing windows and putting things in them.
An X client connects over some sort of socket connection. When the client is on the same machine as the server, this typically is done over unix domain sockets. This does not have to be the case, however. It is quite possile (and often done) to have the client on a separate machine from the host. In this case a TCP/IP network connection is made to the server and the communication is done over that link. While often slower than a connection made on the same machine, it is occasionally faster as the client and server can do their processing simultaneously (this of course requires a relatively fast link).
This aility to have the client run on a different machine than the server gave rise to the idea of X-terminals. Like their text-based brothers, they are essentially computers with no disk drives and a very weak CPU. Unlike their text-ased bretheren, they generally have a good video card. They then allow a user to log in to a powerful computer and run their X clients from that computer. This can have a lot of benefits, not the least of which is that terminals generally require a lot less maintenance than computers.
This is not all, however. The X server provides windowing services and image display services as well as text rendering services. However, it does not provide a way to manage windows. This is the job of a window manager. A window manager provides the borders around windows that allow one to drag them around. Window managers also provide services like buttons that allow you to minimize, maximize, shade, and kill a program. They also tend to provide services such as keyoard shortcuts to launching applications, menus on the desktop, icon trays for when you minimize a window, and virtual desktops.
Virtual Desktops are one of the nicest standard features of X window managers. The basic concept is that the window manager will keep track of where each window is on the virtual desktop. You can then switch to another virtual desktop with different windows on it. When you switch back to the first, it will have the windows that were on that desktop in the places that they were in when you left. It's very convenient as you can set up a number of interacting windows in relation to each other for one task, then set other interacting windows up for another task on another virtual desktop.
There are a few steps involved in setting up an application to do remote displaying (Note: When in doubt, the client machine is the machine from which the program is running. The X server is the machine sitting in front of you):
An X server implements a security access list so that only authorized people can launch windows on the server. There are two ways to grant a machine access, host based and user based authentication. Host based is by far the simplest and is acheived with the command xhost +hostname where hostname is the DNS name or IP address of the machine with the X client on it. As might be obvious, to remove a host from the access list, the command is xhost -hostname. Xhost authentication only works for the duration of the X server's life. Is the X server is restarted, the authentication list must be built again.
The other method is with a program called xauth. It is fairly complicated but provides better security. If you are dealing with a multi-user environment on the client end, investigate using xauth. For more information see xauth's man page (xauth).
The client program must be told what X server to connect to. This is done by one of two methods. The first is the DISPLAY environment variable, and the syntax here is export DISPLAY=hostname:0.0. The hostname is the DNS name or IP address of the machine running the X server. The first 0 is the number of the running X server. This is normally 0 unless the machine is running multiple X servers. If it is, you have to find out somehow which one is the one that you want to use. The second 0 is more of a historical throwback than anything useful.
A variation on this method is to set the environment variable for the execution of the client only. This is achieved by DISPLAY=hostname:0.0 xclientprogram.
The other method is to specify the display on the command line. The syntax varies from program to program, but the general syntax is xclientprogram --display hostname:0.0. Variatons on this are xclientprogram -display hostname:0.0 and xclientprogram --display=hostname:0.0.
This one is pretty simple. Just run the program either by itself or with the arguments as mentioned above in the display section.
This is all there is to running an X app remotely. Please note, though, that this does require a high-bandwidth, low-latency connection to get good response times from the application. On a normal lan the fact that an application is running remotely may not be noticeable at all. However, it might be painfully slow on a modem. For this reason, a low bandwidth extension to X was created called LBX.
LBX is a low-bandwidth extension to X. It is supported by all recent versions of XFree86 and probably by most X servers that have come out within the last few years. LBX is accomplished by having an LBX server on the clients machine which compresses (by various means) the X stream to the real server. LBX will result in higher latency operation when compared to running an X application accross a high-speed lan, but in slow bandwidth situations such as modems it can greatly improve performance.
The exact configuration of the LBX server varies from server to server, but the general idea is that you configure the LBX server for the real X server that you want it to connect to. Then you set up the DISPLAY environment variable on the x-client machine to point not to the real X server but instead to the LBX X server. The whole operation is transparent to the X client program. It needs nothing special to be done to it and all X programs can use LBX without modification except the environment configuration jsut mentioned. You will need to consult the documentation of the LBX server that you use to find out exactly how to set it up.
The only LBX server for linux that I know of is xproxy. It is sometimes also called lbxproxy. The manpage is normally for lbxproxy (i.e. man lbxproxy). If you're interested in using LBX I suggest reading that.