XFree86 10 Years Old

ChazeFroy writes "XFree86 is now 10 years old. To quote from the page, 'What makes this particularly eventful is that it is fully backwards compatible; this is a true testament to the spirit of the original X protocol of which XFree86 is its finest implementation.'" Ten years and still binary compatible. Very cool.

Comments

Re:You're right...

[psamuels]

X is the best thing around that meets the exact specifications that X does.

Yes it is.

For most of us the killer feature is network transparency. There are many windowing systems out there which do a great job of running applications on a local CPU, rendering them to a local graphics card, and taking input from local keyboards and mice. This is, however, very limiting to those of us who have been accessing our machines over networks for the past 10 years. Only recently has the Windows world achieved remote access with decent usability / performance (and I'm still not sure if there's a Windows-based remote access solution that supports input devices other than keyboard + mouse), and most other non-X graphics platforms never even made the attempt.

It's not like we are asking for a bunch of esoteric features that only found in X11. We're asking for one basic feature, network transparency. Those who marginalise this feature probably don't understand what all it can be useful for.

Re:suggested X changes

[ajs]

X standardised Xt,And UNIX standardized dd, but we don't use it for backups anymore do we?

a standard for toolkit interoperability at the component level (it is possible to embedd an Xaw component in a Motif application, for example).

And Xt is about 60% of the reason that Motif blows chunks. There are several serious, objective reasons for this:

• The resource database was difficult to manage because it required encoding large amounts of inherently non-string oriented data into strings
• It was an early attempt to develop an OO model in C. The inheritance model was cumbersome and required far more code to manage than the application itself in almost all cases
• Xt attempted to manipulate events in ways that were terribly inefficient. Especially high on this list of problems were the atificial events created by the widget heirarchy. This above all else made Xt (and thus Xaw and Motif) a painful user experience, and an endless optimization quest for the programmer.

I will not speak of Qt, because I have limited knowledge of it. However, Gtk+ and later GNOME addressed many of these shortcomings in ways that made a great deal of sense. It also did so in ways that were portable to Windowing systems that were either variants of The X-Window System or different altogether, but still provided the basiscs of display manipulation and event model.

The core X Protocol is a wonderful way for applicaiton and display server to talk. XLib is painful, but you can abstract it and still live with it reasonably. Xt was simply unworkable.

Of course, these points are moot. Gtk+ today along with GNOME do much more than Xt or Xaw or Motif ever did, and there's simply no going back. Color management, font management, internationalization, window manager interaction, system- and user-level configuration: These are all things that todays toolkits do far better than was ever available in the bad old days.

Unfortunately, neither Gtk nor Qt honour Xt, nor X's excellent "resource database" generalised configuration and theming (yes, theming!) system.

Of course the way your modern audience here on Slashdot thinks of theming, this is terribly misleading. You could build wildly complex resource configurations that would hand-tweek the widget heirarchy of a specific application. You could also set background colors and such, but since there were no solid conventions (not at all in Xt, and not enough in Motif and Xaw), these were of limited usefulness.