When X Doesn't
Cut It
I'm a consultant. Please don't hold that
against me. This simple fact means that I move around a lot. I move from place
to place many times each year. In each place, I am forced to use different
hardware, software, networks, and so forth.
You already know, because you are reading
this book, that I use Linux. I use Linux a lot. I tend to use Linux to develop
software for every environment, including Windows, because I like the tools
Linux gives me.
I recently had occasion to work in an
environment that I would consider quite atypical. A client was using OS/2 to
build and deploy a 16-bit Powerbuilder application that connected over a
token-ring network to a middle tier implemented using CICS on AIX! Over time, I
managed to get a PC reassigned to running RedHat for a variety of internal
documentation (another adventure, recounted in lang=EN-GB style='color:#003399'>Chapter 9). Now I
had continuous access to my favorite tools. OS/2 even has an X-server, called
PMX, so I could run applications on the Linux box and display them on my
desktop�almost.
lang=EN-GB style='font-size:16.5pt;font-family:Arial'>What Is a Window
Manager?
X-windows is a system that divides the
labor up quite a bit. An X-windows application draws and controls only the
area "inside" the window, the so-called client area. A totally
separate program, called a " lang=EN-GB style='color:#003399'>window manager"
paints the borders and controls (such as resizing edges, maximize, minimize,
and close buttons). You can have only one window manager program per X
server, and that window manager provides these window "decorations"
on behalf of all windows.
The window manager and the X-application
communicate in standard ways. For example, when you resize a window by
dragging an edge, all the work is done by the window manager program until
you release the edge; then the window manager tells the X application about
it by sending it a resize message. The application then must repaint itself
in the new client area. (This is a bit theoretical: Some window managers send
repaint messages while you drag the edge, so the application repaints several
times, but you get the idea.) The application is also able to tell the window
manager certain things, such as whether or not the window may be resized.
The division of labor has some distinct
advantages, especially when you consider X's network capabilities. If the
window manager is local, then when, for example, resizing the window of a
remote application, only the final "window resize" and screen
repaint need go over the network. None of the mouse events or border
animation need to generate network traffic. (Again, if your window manager
sends repaint messages as it goes, this benefit is lost.)
The other advantage is that you can change
window managers. You might have an industrial application that is always
maximized and should not be closed. You could write a window manager that
doesn't have a close button or resizing decorations and that always sets the
client area size to the full screen. Heck, some existing window managers can
be configured to do this without any programming.
The details of window managers and their
interaction with applications can get quite complex. There is a sort of
"minimum standard" set of features a window manager must provide,
and there is a "minimum standard" set of window manager messages an
X-application must support, but many applications go well beyond this. The
increasingly common "desktop" systems for X (KDE and GNOME, for
example) extend this set quite, er, extensively. This means that applications
that use these features either will run only with that one window manager or
will have some functionality unavailable when running under other window
managers.
If you want to know more, it is time for
you to delve into X-windows programming.
VNC is available from the URLs noted at the
beginning of the chapter. As for X-servers for Windows, a number of
commercial ones are available. Since this book is about Free Software,
however, we will not lead you to those.
A free X-server for Windows is available as
part of a product called Cygwin, which is a complete POSIX-compliant
programming environment for Windows. Cygwin actually makes Windows itself
into a decent Unix-like environment. The X-server for Cygwin is the same
X-server shipped with most Linux distributions: Xfree86.
Cygwin is available from Cygnus Software,
which was purchased by RedHat last year. The URL is style='color:#003399'>http://sources.redhat.com/cygwin.
I found that a great many "normal"
applications, such as Wine (see lang=EN-GB style='color:#003399'>Chapter 17) and
the GIMP (see lang=EN-GB style='color:#003399'>Chapter 22) would
crash the OS/2 PMX server. Not only that, but the OS/2 PMX server insists on
using OS/2 Presentation Manager as the window manager. (If you do not know what
this means, see the "lang=EN-GB style='color:#003399'>Window Manager"
sidebar.) I found myself with a classic problem: How, if Linux is not my
primary system, do I get a decent X-server?
This problem exists for Windows users as
well. There are a couple of free X-servers out there for Windows, but they are
quite limited in capability. There are some excellent commercial X-servers for
Windows, but if you are like me, your software budget is limited (nonetheless,
we will list URLs for a few of the commercial ones as well).
I began looking for alternatives. I was
already familiar with something called VNC,
which stands for "virtual network console" and is similar to
PC-Anywhere. It basically allows you to access another machine's console as if
you were sitting at that machine. To understand the differences, we will have
to review the design of X and of VNC (lang=EN-GB style='color:#003399'>Figure 2-1).
lang=EN-GB style='font-size:10.5pt;font-family:Arial'>Figure 2-1. Block diagram
of an X-windows environment.
No comments:
Post a Comment