Slashdot Mirror
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.
The problem with this is that X is intended as a much lower level toolkit. X is what you you when you want to create a widget set such as Qt or GTK or Motif of Athena. As far as X is concended (and rightly so), widgets are "someone elses job"
X rules:
- it's flexible, allowing a multitude of different window managers to front-end for it
- it's network portable, allowing me to run X-sessions off another box completely over a ssh-connection
- it's cross-platform, running on almost any architecture and operating system (with the obvious exceptions of course)
- it allows me to run a screensaver in root-window as background, dazzeling all those MSWindows folks =)
- it's free!
In my opinion, there are very little GUI's able to beat that, not OSX for all it's beauty but lack of flexibility and not MSWindows for it's compatibility but ugliness.
---
"The chances of a demonic possession spreading are remote -- relax."
X standardised Xt, a standard for toolkit interoperability at the component level (it is possible to embedd an Xaw component in a Motif application, for example).
Unfortunately, neither Gtk nor Qt honour Xt, nor X's excellent "resource database" generalised configuration and theming (yes, theming!) system.
Gtk because it was written by a bunch of people initially without the faintest clue how X actually works, and Qt because Qt is like "Swing for C++" - it's intended to be cross-platform, and thus handles most drawing "itself", merely requiring prettu much a dumb framebuffer underneath.
Thus, the two most popular toolkits on Linux are abysmal from an X standpoint.
Er... the window manager doesn't supply a clipboard. The X selection mechanism does - it's major problem is that, for reasons of statelessness for easy network-transparent operation, the "cut"/"copied" clipboard only lasts as long as the source - i.e. there's no independent "buffer" for the clipboard - it was always the X designer's intent that a clipboard daemon be used (just like the one that is deeply buried on windows, BTW), but people didn't progress it beyond the proof-of-concept xclipboard, which only handles text/* mimetypes..
I wish I could be as excited about XFree86, but for all the years I've used it, it still doesn't touch the responsiveness of my Windows computer. I'm not trolling, just stating my experiences. Simply dragging an X window in any window manager for me creates a trail of artifacts behind it that I can see being drawn over. This is on my 266mhz. On my old 66mhz, on the other hand, Windows 3.1 is smooth and responsive. I'm not even going to go into the complexities of configuring X, which has thankfully improved a bit over the years but not by much.
I just wish XFree86 was faster and easier to use. Needless to say, Linux remains in text mode most of the time whenever I use it. Hopefully, I'll have better experiences with XFree86 on better hardware.
The trails you see have very little to do with your CPU and everything to do with your graphics accelerator. If you're seeing artifacts or slowness on a 266MHz (or even 66MHz) machine, your accelerator chip is either lacking proper accelerated drivers or is misconfigured.
STOP . AMERICA . NOW
All drawing would be done by the library in the displaying machine.
The tradeoff is that X was originally designed 10 years ago to work with thin clients. A thin client is supposed to have nothing but a video card and the X client. If you add a widget library, on what storage space do you put it? Not to mention storing the user preferences for the window mananger and widgets. Also not to mention the extra processing necessary to render the widgets.
To a thin client, especially one designed when X was first designed, storage space and processing power are much more limited than bandwidth.
And if you can live without KDE's pretty eye candy or 3D screensavers, even a broadband wire to the server will be more than enough (hint, Motif may be ugly, but it works for its purpose).
By what definition of "monolith"? The five or six client libraries you may or may not need to link to? The separation between client and server for display? The (optional) separation between graphics server and font server? The separation between graphics server and window manager? The separate client libraries for low-level network protocol and widget set? The loadable modules which implement everything from hardware backends to input device drivers to font rasterizers? The separation between user-space and kernel-space components (particularly for 3D graphics rendering)?
Which of the components I have mentioned so far is the "monolith" of which you speak?
"How can you claim that you are anti-crack, while still writing a window manager?" — Metacity README
okay.m l
http://www.cat.org.au/maffew/cat/xfree-dawes.ht
here's an interview, a few years old now unfortunately, but it covers a bit of the history of X11. it's an interview with the XFree86 leader, david dawes.
But I don't care anymore. I use X at home and hope my job decide to make MSWindows XWindows someday.
Yes, I'm Blacking Out right now, or whatever...but this just had to be said.
The one comment that gets put out there by opponents of X *time after time* is that it's old and cobbled together. This is seen as a bad thing.
Then there's some MS article, where everyone attacks their old compatibility layers and old implementations.
Now, a story on XFree's birthday rolls around. "It's still compatible with stuff 10 years old!" Well good for you. Why is that a good thing? Sometimes the old has to go if you want to properly implement the new.
If there's one protocol that has been overridden adn axtended in more unnatural ways than X, it has to be HTTP. (At least X was intended for applications from the outset.)
± 29 dB
No - not yet anyway. It is interesting to look at how the X display model has held up over the years. As most of you know, the DISPLAY=myhost:m.n specification allows for multiple hosts (addressed by TCP/IP), multiple display servers per host (doing business on separate TCP ports, 6000+m), and multiple screens per display. Each display has a single set of input devices, which is shared across however many screens it has.
The X protocol designers clearly saw the need for multiple display servers per machine, and this is used for many things - most often, perhaps, running multiple X sessions on a single head, which you can switch between, but also running "fake" X servers which are actually tunnel endpoints with ssh or lbxproxy. However, the multiple-screens capability has mostly gone unused - since it would force an application to specify a particular screen number when drawing a new window. Applications shouldn't have to care about confining windows to particular monitors, so the usual solution is for the X server to present a single logical screen (SLS) larger than any one physical screen. This is one of the few instances I know of where the X protocol turned out to be too general.
OK, back off the tangent. What you propose is sort of the opposite to the screen model, and it won't work, at least not the way X is designed currently. Basically, all applications on a desktop have to use the same core pointer (mouse) and core keyboard. Why? Because the X server is only geared to showing one mouse pointer on the screen, and the window manager must know unambiguously where it is at all times so it can raise windows to the foreground, switch input focus, etc. And speaking of input focus, there is no provision within the ICCCM [the standards and guidelines for X window management) for keeping track of application keyboard focus with multiple keyboards possibly targeted to multiple applications.
In short, the keyboard and mouse must be common to all clients of a specific X server. That in turn implies that you couldn't set a client variable to use such-and-such a mouse or keyboard, since there's no way to guarantee that all clients have the same variable set. You'd have to configure it at the server end.
Which isn't to say you couldn't write an X input driver that internally gets its data from TCP/IP or bluetooth or something....
"How can you claim that you are anti-crack, while still writing a window manager?" — Metacity README
The core X Protocol is a wonderful way for application and display server to talk. XLib is painful, but you can abstract it and still live with it reasonably.
For an Xlib alternative in its early stages, check out XCB, a lightweight, transparent X protocol C Binding. One of the beauties of the X protocol is that sticking a new (and hopefully "better") API on top of it is relatively straightforward.