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!
Virtually every toolkit out there uses xlib. It really isn't
"little used", but rather key part of the whole *nix desktop.
XFree86 Has Not Merged With X.Org (see News)
[23 January 2004] http://www.xfree86.org/
So have they merged or not merged?
It's a message queue for programs to take advantage of. Just a simple way to communicate between desktop applications. I think they're planning on using it in the Dashboard project.
True story.
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.
They got rewritten from scratch. :)
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.
X11 and The X Window System (not, they stress "X Windows" because that sounds too much like MS Windows) are the same thing. Just different names for it. It's the base window system.
The group that releases the standard X code distribution, specifications for new versions of X, etc is the X Consortium, X11 is, more fully, X11R6--X Window System version 11 release 6. If X11R7 happens, it'll come from the X Consortium. Their web site is x.org.
XFree86 is the group that does the free version of the X Window System, originally for Intel x86 systems (hence the name) but nowadays for pretty much every system that'll run a free OS.
Freedesktop.org works on higher level standards, like drag and drop and such. Stuff that lets the various apps running under X11 to interact but not low enough to be under the jurisdiction of the X Consortium.
--AC
From The DCOP site:
So DCOP does depend on Qt. Also, it is written in C++, whereas the GNOME libraries are almost always written in C (I'm not saying this is better, this is just how it's been done). Until DCOP doesn't depend on Qt and gets a binding to C, I see no reason why the GNOME project shouldn't pursue DBUS. (Had to post as AC because I have bad karma...)
fraggle@yaffle:~$ ldd
libX11.so.6 =>
fraggle@yaffle:~$ ldd
libX11.so.6 =>
were you expecting to see a sig here? perhaps you'd rather see the inside of an ambulance!
Now, I know I'm responding to an Offtopic troll, but...
OpenGL is an API for talking to a Vector and/or Raster drawing subsystem. It works for 3d and 2d drawing. Where hardware acceleration for vector drawing exists (ie most modern desktops) OpenGL can send the drawing commands direct to the Video Card, without rasterizing the result first. This means that vector applications (such as SVG rendering) can operate a whole lot faster, and are simpler to code.
Where the application is not running on the same machine as the display, sending GLX vector commands rather than rasterized images can be much faster. Also, it does not load the machine significantly more than having application-side rasterization where acceleration hardware doesn't exist.
So by working on OpenGL (which is mostly a server issue, not an XLib issue), developers are working on SVG, Animated Everything, and faster 2d.
GTK on the framebuffer is quite nice. Aside from the nice transparency effects in the screenshots, it's really quick. Hopefully we'll see a LiveCD come along soon with GTK on DirectFB so people can evaluate it without jumping through a great many hurdles. I bet a great many GNU/Linux/BSD users don't need or even know about the many features of X11 like network transparency, let alone use them.
:) I could be wrong about that, but it seems to be more modular, and lightweight.
I like to think DirectFB is to X11 as Hurd is to Linux. ( in design - not availability
With that said, congrats to freedesktop.org. They are becoming more and more valuable to our little community every day it seems.
GDK is basically a wrapper around the standard Xlib function calls. If you are at all familiar with Xlib, a lot of the functions in GDK will require little or no getting used to. All functions are written to provide an way to access Xlib functions in an easier and slightly more intuitive manner. In addition, since GDK uses GLib (see below), it will be more portable and safer to use on multiple platforms.
D-BUS wasn't something the GNOME people thought up. The freedesktop.org people modeled it after DCOP, but made it independent of KDE's framework so the GNOME people could use it. The plans for D-BUS in KDE seem uncertain. Some developers want to just ditch D-COP entirely and use D-BUS, since D-BUS is similar. Others want to bridge D-COP and D-BUS, and retain D-COP for intra-KDE communication, and use D-BUS for inter-desktop communication.
A deep unwavering belief is a sure sign you're missing something...
Everyone. Right now, there are two ways to communicate with X-server.
XCB - A new, low-level binding designed for big toolkits like Qt/GTK+ that can handle their own caching, buffering, etc.
XLib - An older, higher-level binding originally released with X.
Currently, almost all apps still use Xlib, as do all toolkits.
A deep unwavering belief is a sure sign you're missing something...
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.
The XServer got rewritten from scratch*. The xlibs are an evolution of the XFree86.org code.
*> Well, not really. The FD.O X server is based on Keith Packard's KDrive (AKA TinyX) server, which is a vastly restructured and rewritten XFree86.
A deep unwavering belief is a sure sign you're missing something...
If I read it correctly, they are replacing the Imake buildsystem with GNU autoconf/automake - a good thing I think. Other than that I don't know what the differences are (going to be), but they will probably try to integrate some of the other parts of the freedesktop platform.
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.
The way I understand it, Havoc Pennington said that several X.org and XFree86 developers were working together. This was misinterpreted by journalists as the projects working together.
Hmmm.
The plan is to eventually rewrite Xilb as well.
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.
Yup, the freedesktop plan is to turn xlib into a compatibility shim on top of XCB for legacy stuff.
This is pretty cool, because it means that the core of X11 is going to get overhauled, but most users won't know that it's happening (although they might notice the better performing eyecandy).
i don't know about windows, but osx uses GL for most/all graphics. fdo's xserver aims to do the same thing. it's a completely new X server based on keithp's kdrive. afaik xfree doesn't use GL for anything 2D.
Pretty much where I was coming from. I have also messed around, hacking around broken stuff, with both Imake and autoconf/automak based stuff, and Imake just looks worse (maybe it would be different if I had some experience with either, but just fixing a broken link parameter and that sort of thing seems much simpler with auto*). And if it gets the options of X into a configure script instead the host.def file, then I wont complain (force of habit I guess).
There are lots of pieces to the recent work that's been happening on X under the freedesktop banner. Here's my understanding of what the pices are...
Xouvert was/is also working on build changes (and quite possibly this release is based on their work - I don't really know). In any case. the freedesktop.org xlibs announced here (http://xlibs.freedesktop.org/) release has actually got them all made (quite possibly based on contributions from xouvert) and is a full set of 'split' xlibs which build with autoconf/pkg-config.
Additionally, freedesktop has at least two other major X-related projects going (some of the same people, some different). One of these is the xcb/xcl to replace xlibs, the other is a kdrive-based xserver. Neither of these projects has yet made a full release, though both have code that works and is making excellent progress
xcb (http://xcb.freedesktop.org/) is a new API targeted toward letting toolkit authors handle asyncronous events more effectively, without some of the compromises xlib made to ease writing apps directly to it. The rise of high-level toolkits (Qt, GTK, wxWindows, Tk, etc) has definitely changed the way the xlib API is typically used. For compatibility with existing apps and for easier programming of apps which (for whatever reason) do not want to use a high-level toolkit, xcl is a an xlib-compatible API sitting on top of xcb. Think of it as a minimal 'toolkit' which provides the 'wait-for-reply' API to error handling and return-values that xlib uses today.
The new kdrive xserver's primary features are the DAMAGE and COMPOSITE extensions (allowing multiple apps to coordinate and share in painting what actually appears on the screen. It also features a much smaller&simpler codebase from the XFree86 server, allowing easier experimentation with still other new ideas.
The Matrix is going down for reboot now! Stopping reality: OK. The system is halted.
In fact this is one big reason to use glib: it makes it very easy to support UTF-8 and other things in a portable (to windows) way.