freedesktop.org xlibs 1.0 Released 243
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!"
Re:Who uses Xlib (Score:5, Informative)
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.
Little used ? (Score:3, Informative)
"little used", but rather key part of the whole *nix desktop.
XFree86 Has Not Merged With X.Org ?? (Score:5, Informative)
XFree86 Has Not Merged With X.Org (see News)
[23 January 2004] http://www.xfree86.org/ [xfree86.org]
So have they merged or not merged?
Re:Nethack X is slow ... (Score:1, Informative)
Re:Not that X is slow ... (Score:5, Informative)
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.
Re:vs XFree86 ? (Score:3, Informative)
Re:Who uses Xlib (Score:5, Informative)
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.
Re:Too many damn x's! (Score:5, Informative)
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.
Re:Too many damn x's! (Score:3, Informative)
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
Re:Nethack X is slow ... (Score:3, Informative)
From The DCOP site [kde.org]:
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...)
Re:Who uses Xlib (Score:3, Informative)
fraggle@yaffle:~$ ldd
libX11.so.6 =>
fraggle@yaffle:~$ ldd
libX11.so.6 =>
Re:3d interfaces are a joke. (Score:4, Informative)
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.
Re:Who uses Xlib (Score:2, Informative)
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.
Re:Xlib is trash. (Score:2, Informative)
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.
Re:Not that X is slow ... (Score:4, Informative)
Re:Who uses Xlib (Score:3, Informative)
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.
Re:Any idea on the total size of the libaries? (Score:5, Informative)
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.
Re:vs XFree86 ? (Score:4, Informative)
*> 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.
Re:vs XFree86 ? (Score:3, Informative)
Re:Too many damn x's! (Score:5, Informative)
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).
Re:Nethack X is slow ... (Score:5, Informative)
Re:Little used ? (Score:3, Informative)
As indeed the rest of that sentence indicates: "... libraries that kind of power your whole desktop." Try twiddling the knobs on your humour meter.
Re:XFree86 Has Not Merged With X.Org ?? (Score:3, Informative)
Hmmm.
Re:vs XFree86 ? (Score:1, Informative)
Re:vs XFree86 ? (Score:5, Informative)
Re:vs XFree86 ? (Score:5, Informative)
Re:vs XFree86 ? (Score:1, Informative)
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).
Re:Accelerated Desktop (Score:2, Informative)
Re:vs XFree86 ? (Score:3, Informative)
Re:vs XFree86 ? (Score:2, Informative)
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.
Re:Not that X is slow ... (Score:3, Informative)
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.