Slashdot Mirror
freedesktop.org xlibs 1.0 Released
Daniel Stone writes "A short time ago, freedesktop.org xlibs 1.0 was released. Simply put, this is the collection of libX11, libXext, and other little-used libraries that kind of power your whole desktop. The xlibs team at fd.o are now maintaining all these libraries, and more, and we're going to be making releases as part of the fd.o platform, which is far more wide-ranging, but it still forms an important part of the platform. Share and enjoy!"
What is your definition of "Doesn't depend on"?
They both use xlib exclusively for drawing!
QT (and possibly GTK) exists in a version for embedding/framebuffer devices, but that's not the version you see in everyday KDE/Gnome.
With great numbers come great responsibility!
XFree86 Has Not Merged With X.Org (see News)
[23 January 2004] http://www.xfree86.org/
So have they merged or not merged?
D-BUS is the replacement for DCOP. "Agnostically" written in C this time to help GNOME developers swallow (not so agnostically though since Glib kept sneaking in, but fortunately got replaced in the end).
It does have a few neat features that DCOP doesnt. Like being system-wide, and thus support signals from the kernel (implemented by HAL) and signals from other non-desktop application like Apache.
Every single X program uses xlib directly or indirectly. So GTK always uses it, and QT uses it except when using a framebuffer directly or using some other underlying mechanism (like non-X11 Mac, IIRC).
Chances are that X isn't what's crashing for you, but rather some program running under X (unless you have hardware problems, a bad driver, a corrupted X server, or something like that). X is also generally quite fast, but most programs (such as any that use GTK or QT, except for really recent ones) use it extremely badly.
Actually, what is generally slow about X is that is doesn't have the drawing primitives that modern interfaces want to use, so they have to implement them inefficiently with the available primitives. Present development is helping to rectify this situation, however.
x.org == X Consortium
X11 == X Window System 11
X Window System == A windowing system, consisting of a client and a server that communicate via an open protocol. Many different vendors distribute X clients and servers, commercial and free.
The X Consortium manages the X protocol and distributes a reference implementation of clients and servers. XFree86 is a fork of the X Consortium implementation that was originally intended to run on x86-class machines -- thus the name. Freedesktop.org is a loose coalition attempting to corral all the competing *nix desktop software into a cohesive whole by setting up standards. They also provide support for a project that is working on an improved client and server for X11.
The fd.o xserver is about 1 mb, and the X11 libraries to drive your apps weigh in at around 1 mb or so stripped, I think. At least on my fd.o installation they do. Also kdrive + libs + gtk2 + apps runs comfortably on a device like the Zaurus. Of course that's with no openGL stuff, or xinerama or xprint. But it does include freetype, xft, xrender, xdamage, composite, etc. The basic libraries are quite compact. If you really look at it, 1mb for kdrive, 1mb for libraries, plus maybe 5 mb for gtk2, an X11-based enbedded environment (supporting just one kind of display hardware) is very light and competitive with the Qtopia framebuffer system. Given that, I can't see any reason do use qt-embedded or gtk-fb for most things.
Some of those things in your list are not really libraries providing an api, but rather utilities, many of which on an embedded environment aren't needed.
X11 - The protocol spoken by modern X servers.
x.org - Formerly the X Consortium, an organization of X-using businesses, like the OpenGL ARB. They are responsible for changes to the spec.
X Windows - Shorthand for X Window System --- refers to the whole thing, servers, libs etc.
freedesktop.org - A new organization dedicated to making standards for the *NIX desktop. For example, they have specified a common MIME framework, common menu format, common window manager specification, etc. Many of these, (ex. the window manager specification) have already been adopted. They are also an umbrella project for other projects for improving the X desktop. For example, D-BUS which is the new messaging system developed for KDE and GNOME, is a freedesktop.org project. Keith Packard and others are also developing a new X server under the freedesktop.org umbrella. This new X server already supports complete-back buffering of windows (each window gets its own buffer, like OS X, to make moving windows smooth and free of redraw) and window compositing (for transparency, shadows, other effects). They are also restructuring the driver API to support OpenGL independent of X, so the X server can sit on top of OpenGL and use it to accelerate drawing. At the same time, they are also introducing new extensions (Xfixes, XDamage, etc) to allow applications to access the extended features for the new server, as well as working on existing extensions (XRender) to improve their implementation (add acceleration via OpenGL, for example).
A deep unwavering belief is a sure sign you're missing something...
AFAIK DCOP doesn't depend on Qt directly and has C-bindings. The problem is with depending on C++, and depending on Qt for communicating with KDE-programs. Many KDE-programs uses the Qt-internal structures to stream over DCOP, that makes it very difficult to communicate with them without Qt.
Its not so much its superiority to imake, as its superiority to the imake setup of XFree86. The XFree86 build scripts are horribly complex to understand, and while autoconf/automake suck too, they suck less. Plus, more people are familier with them, so there is less of a learning curve for developers.
A deep unwavering belief is a sure sign you're missing something...
Mostly they've just changed the build system. Someone mentioned that they're using automake/autoconf. But that's only a minor part of it. The big thing is that they're making it so that you can compile these libraries without having the entire X11 tree. X until now was this giant monolithic source tree with tons of interdependancies so you'd have to build it all at once. Their first goal is to modularize X and that means making the Xserver, Xlibs and the basic X programs all build separately.