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!"
Little used ? (Score:3, Informative)
"little used", but rather key part of the whole *nix desktop.
Re:Little used ? (Score:2)
Re:Little used ? (Score:3, Funny)
#include <irony.h>
Sorry 'bout that.
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.
Not that X is slow ... (Score:3, Insightful)
What's the DBUS ? (Desktop bus ?)
Simon
Re:Not that X is slow ... (Score:2, Flamebait)
Not to badmouth it (well, I am biased), but I've heard that the KDE people plan to integrate DBUS into KDE to make GNOME apps integrate better. I'm all for it.
Re:Not that X is slow ... (Score:4, Informative)
Re:Nethack X is slow ... (Score:2)
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 DBU
Re:Nethack X is slow ... (Score:5, Informative)
Mod parent down... -1 Incorrect (Score:2)
Re:Not that X is slow ... (Score:4, Funny)
It's dthing you get on to go to work in when you don't want to get dcar out of dgarage mon.
Or, put another way, I don't have a fscking clue so, in the greatest tradition of
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:Not that X is slow ... (Score:3, Funny)
Re:Not that X is slow ... (Score:4, Interesting)
Glib 2.0 also includes GObject, the core object system on which Gtk+ and Gnome are based, though again, you could write grep using these objects, they're not graphics-specific.
Re:Not that X is slow ... (Score:5, Insightful)
I think glib (at least the routines for data types -- lists, hash tables, strings, etc) should be in the C standard library. The gobject stuff, while useful, should always be in a separate library.
Re:Not that X is slow ... (Score:2)
Re:Not that X is slow ... (Score:2, Insightful)
glib is incredibly convenient to program in because it has no error handling. Your app just goes boom if something unexpected happens, like a memory allocation failing. You can kind of prevent your program for totally blowing up, but you don't have the ability to correctly handle errors (at least in glib 1.2, don't know if 2.0 fixed this - we're talking about a nontrivial change here).
Great for building toy programs, but absolutely terrible for building a pr
Re:Not that X is slow ... (Score:2)
glib is incredibly convenient to program in because it has no error handling. Your app just goes boom if something unexpected happens, like a memory allocation failing.
Yeah. Of course that's what most versions of the Linux kernel do as well: when they run out of memory, they just start killing processes, rather than returning NULL (with the wonderful rationale that this would break programs that don't check for malloc errors). You can change that behavior by disabling overcommit, sort of, but it's still
Re:Not that X is slow ... (Score:2)
That's the point (Score:2)
IMHO, every major C project should use glib
..which is why DBUS should *certainly* not depend on it, if they want the C++ projects like KDE to use it. Using Glib in KDE is pointless, since you have Qt which can do everything GLib can do already, arguably better.
Re:That's the point (Score:2)
In C++, the standard library does almost everything that GLib does, and arguably better.
While there are a few things which are not so platform-agnostic which GLib does that the C++ standard library doesn't (like handling dynamic libraries), there are a lot more things that the C++ standard library does that GLib doesn't. Just typing "sort" and letting the library optimise it depending on whether it's called on a dynamically-sized array, doubly- or singly-linked list or a funky container which you just wro
Re:That's the point (Score:4, Insightful)
"Using Glib in KDE is pointless"
Using glib in DBUS is not however, and using DBUS in KDE is not... moot point. Also keep in mind that KDE's reliance on C++ and C++'s platform difficulties (SOME of which went away with the finalization of the ANSI standard a few years back) was exactly the reason that Sun had to choose Gnome as their desktop, even though they prefered KDE at the time. They had to support two compilers though, and if you can't lock customers into a compiler, C is the only way to fly (Java is as close as it gets otherwise, and it might be ok after another decade or two to mature).
I'm not language zeloting here... I see the value of C++ accedemically, but building software in it DOES cut you off from the rest of the world in the sense that the many, many thousands of C-based software projects and products in the world then have a hard time making any use of you at all.
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.
Re:Not that X is slow ... (Score:2)
Not that you didn't search ... (Score:2)
Re:Not that X is slow ... BUT IT IS! (Score:2)
-Don
Re:Not that X is slow ... BUT IT IS! (Score:2)
X has been quite fast in practice too. SGI shipped a very high-performance X implementation. The main issue is that
X is extremely inefficient on the network. (Score:2)
X-Windows was designed to be a distributed window system, to operate over the network.
Yet it was foolishly not designed to support extensibility: dynamically downloading code to the server to perform local input processing, feedback and graphics, and to vastly reduce the amount of network traffic.
If your web browser h
Re:X is extremely inefficient on the network. (Score:2)
---
Yep.
Yet it was foolishly not designed to support extensibility:
---
Yes it was. Might want to clarify your definition of "extensibility."
dynamically downloading code to the server to perform local input processing
---
Input processing is handled by the application. There is no need to download code into the server to do this. You need a safe language to do this (to avoid crashing the server with bad downloaded code), and
Re:X is extremely inefficient on the network. (Score:2)
What do you mean by "is"? "Should always be in every case"? Or "X-Windows has always forced us to do it this way"?
Says who? I certainly see a need. Would you want to run an X-Windows server on a cell phone, where you have to pay for bandwidth and wait for round trips? Nope.
A NeWS-like architecture is much more efficient for implementing distributed applications on cell phones, because it perm
Re:X is extremely inefficient on the network. (Score:3, Insightful)
---
X makes you do input-processing application-side, but that doesn't really introduce an inefficiency. The data rate of a mouse/keyboard even uncompressed never approaches more than 100 bytes/second. That's really not a bottleneck for the roles X is aimed at.
Says who? I certainly see a need. Would you want to run an X-Windows server on a cell phone, where you have to pay for bandwidth and wait
4Sight (Score:3, Interesting)
You must be talking about 4Sight, SGI's window server that integrated both X11 and NeWS 1.1 (Network extensible Window System). Thanks the NeWS, clients could make efficient use of the network bandwidth by downloading PostScript programs into the server, which executed locally and only sent responses over the network when absolutely necessary.
In 1988, I helped develop the NeWS driver for UniPress Emacs. James Gosling wrote UniPress's version of Ema
Re:4Sight (Score:2)
---
You most likely cannot do it in X Windows. But the needs of applications have changed a great deal since then. Consider doing text and graphics highlighting on an HTML page. HTML layout is extremely complex, and the layout data can be very large. Instead of a simple array of integers
Re:4Sight (Score:2)
Which brings us back to my point, that "doing it on a web page" is using a NeWS-like architecture.
So what possible advantage is there to have the enormously complex layer of X-Windows in there, between the web browser and the operating system?
X-Windows is not solving any problems, if it's just introducing another huge layer that g
Re:4Sight (Score:2)
---
Huh? I'm talking about rendering the web-page itself. Consider doing text-highlighting of an HTML page server-side. Its doable if you build-in all the logic of displaying a web-page into the server. For every application that has different display logic (word processor, spreadsheet, etc), you have to download all that display logic into the server. And you have to send large amounts of data over the wire to
Re:4Sight (Score:3, Insightful)
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:XFree86 Has Not Merged With X.Org ?? (Score:3, Informative)
Hmmm.
Re:XFree86 Has Not Merged With X.Org ?? (Score:2)
I'm going to go now and boot up my Windows Media Center PC more quickly using Linux!
Re:XFree86 Has Not Merged With X.Org ?? (Score:2)
As in: "Somebody stuck a fork in XFree86, I think they're done." ;)
Re:XFree86 Has Not Merged With X.Org ?? (Score:4, Insightful)
Some developers that have at one time or another been associated with XFree86 are participating in the reformation of X.org. How that translated into "XFree86 and X.org have mereged" in the headline is beyond me.
Harold
Any idea on the total size of the libaries? (Score:2, Interesting)
From the site:
This table represents the state of libs from XFree86 that should be brought into the Freedesktop cvs as autofooed projects. Please update these if you have any further information.
Library current status
GL needs to be done
GLU FreeGlu? may be better? (don't think so, and Mesa should have the same libGLU available --EricAnholt)
GLw
XThrStub? would be part of libX11, but
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.
vs XFree86 ? (Score:5, Interesting)
Re:vs XFree86 ? (Score:3, Informative)
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:2)
Re:vs XFree86 ? (Score:3, Informative)
Re:vs XFree86 ? (Score:5, Informative)
Re:vs XFree86 ? (Score:3, Informative)
Re:vs XFree86 ? (Score:5, Informative)
Re:vs XFree86 ? (Score:2)
libXext 6.4.2, and they say:
So do these extensions work with regular XFree86-Server or will they use their own i
Re:vs XFree86 ? (Score:2)
As for what they have actually improved, as I understand it, they are making their Xlibs more modular, more efficient, more modern, etc. Probably not anything that a user wou
Too many damn x's! (Score:3, Interesting)
X11, x.org, xfree86, X Consortium, X Window(s?), not to mention freedesktop.org which is commonly mentioned in the same breath - i'm sure i'm missing some.
I'm sure there's others that would appreciate an unscrambling of the relationships between the x's
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:2)
xxxxxfreedesktop.orgxxxxxx
Re:What is X-Windows? (Score:2, Funny)
What it does by itself is anyone's guess. Probably low-level graphics calls.
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 Sys
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:Too many damn x's! (Score:2, Insightful)
Re:Too many damn x's! (Score:2)
Eh? Brimstone is a solid at room temperature. Do I win a Nobel prize? :-)
weird naming (Score:3, Funny)
mount
Am I using this wrong?
Re:weird naming (Score:2)
Re:weird naming (Score:2)
Re:weird naming (Score:2)
mount
Share and WHAT?! (Score:2)
Are you Sirius?
How does this relate to XFree86 (Is it a fork?) (Score:3, Interesting)
IIRC, Debian already uses libXft from fd.o (which is a bit obvious, as Keith Packard is in fd.o).
Things That Happen When You Say X-Windows (Score:3, Offtopic)
Things That Happen When You Say 'X Windows'
THE OFFICAL NAMES
The official names of the software described herein are:
X
X Window System
X Version 11
X Window System, Version 11
X11
Note that the phrases X.11, X-11, X Windows or any permutation thereof, are explicitly excluded from this list and should not be used to describe the X Window System (window system should be thought of as one word).
The above should be enough to scare anyone into using the proper terminology, but sadly enough, it's not. Recently, certain people, lacking sufficient motivation to change their speech patterns, have fallen victim to various 'accidents', or 'misfortune'. I've compiled a short list of happenings, some of which I have witnessed, others which remain heresay. I'm not claiming any direct connection between their speech habits and the reported incidents, but you be the judge... And woe betide any who set the cursed phrase into print!
You are forced to explain toolkit programming to X neophytes.
Bob Schiefler says, "You should know better than that!"
The Power Supply (and unknown boards) on your workstation mysteriously give up the ghost.
Ditto for the controller board for the disk on your new Sun.
Your hair falls out.
xmh refuses to come up in a useful size, no matter what you fiddle.
You inexplicitly lose both of your complete Ultrix Doc sets.
R2 won't build.
Bob Schiefler says "Type 'man X'".
Your nifty [livejournal.com] new X screen saver [jwz.org] just won't go away [jwz.org].
The window you're working in loses input focus. Permanently
-Don [donhopkins.com]
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.
Re:Who uses Xlib (Score:2, Informative)
I like to think DirectFB is to X11 as Hurd is to Linux. ( in design - not availability
Some of us (Score:2, Interesting)
Re:Some of us (Score:4, Insightful)
Yeah, and what kind of non-bloated non-gtk/qt applications do you run in your non-bloated window manager?
psavo, a wmaker user himself
Re:Who uses Xlib (Score:5, Insightful)
And X is NOT slow. For what it does, it does it quite efficiently, and it even has network transparancy thrown in for "free", because of the way it works. Just because the code base of XFree86 is a bit aged and has accumulated a lot of cruft over the years, doesn't mean the initial design is flawed. It was ahead of it's time, and it's still relevant.
Oh, and X works pretty good for me. Haven't seen a crash because of X in years. Maybe it's something else (buggy driver? broken hardware?) that's plagueing you. It's not X, in any case.
Re:Who uses Xlib (Score:5, Insightful)
He is right about X not being slow. The problem is the perception thats X is slow. X is what is visual to the user, users either blame KDE/Gnome or X.
Take a pre-emptive low latency linux kernel and run X on it, its like night and day, its smooth, fast, which proves its not X but the kernel.
Windows cheats and loads the gui extremely fast, but if you watch your hardrive light, and tool tray, you will noticed things are still being loaded in the background. The system is busy for a few more seconds. You can load an application, and it waits till after the services start.
So, X seems slow compared to other OS's.
1. Long delays to get into KDE/Gnome, and actually use the system.
2. Slow response on user input.
3. Multitasking, switching apps pause the system.
4. Loading directories in ICON/Image view takes longer than windows.
5. Lindows has everything running as Root for a speed boost.
I predict we will see pre-emptive, low lantency kernels as standard on Mandrake and Suse. Preemptive kernels are now standard on 2.6.x (well, if you check the box). And even more pre-linking to help boot time.
BSD has the same issues. Apple's X server does seem faster than both Linux & BSD. I'm only running window maker on it, so its not an exact match, but task switching and running gimp does seem more reponsive.
Could the answer be the mach kernel osx uses? Maybe we need a new suite of benchmarks for user interaction. (os+X+wm/etc).
-
I code in my SecondLife [secondlife.com]
Re:Who uses Xlib (Score:2)
Re:Who uses Xlib (Score:2)
Thanx for bringing this up. I was about to say this exact thing (until I scrolled further and saw your post...).
Throwing a crappy 5 year old PCI vidcard in a box to "try out" "Linux"* will indeed give a person a rather negative opinion of X. Personally, I had a nVidia TNT-2 in this machine and X ran far better than Windows ever dreamed of running on the exact same hardware (dual boot just for testing Windows). Got a lot b
Re:Who uses Xlib (Score:2)
So, you're saying X by itself is as slow as both Windows AND its services loading up?
I don't know about you, but my Linux services get loaded before X starts up.
Re:Who uses Xlib (Score:2)
Besides having drivers, as others have mentioned, Apple also did some (proprietary: not available for the publick) work on their implementation of the X server. Could be that. I can't be more specific (read: don't know more), but there was a link to an article here on
Re:Who uses Xlib (Score:2)
Re:Who uses Xlib (Score:4, Funny)
Re:Who uses Xlib (Score:2)
I see very little of the slowness everyone trolls about, though if you want to improve it, one should implement some better redrawing algorithms in the toolkits. And write some better gfx card drivers. Though that is hard, graphics is hard. And vendors do seldom hand out hardware specs to everyone.
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:Who uses Xlib (Score:3, Informative)
You are wrong.
/usr/lib/libgtk-x11-2.0.so
... /usr/X11R6/lib/libX11.so.6 (0x402e8000)
...
/usr/lib/libqt.so.3
... /usr/X11R6/lib/libX11.so.6 (0x4081f000)
...
fraggle@yaffle:~$ ldd
libX11.so.6 =>
fraggle@yaffle:~$ ldd
libX11.so.6 =>
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:Xlib is trash. (Score:3, Insightful)
I triple dog dare you (not necessarily the parent troll, but the general audience) to find a binary or library capable of displaying on an X11 display that's not linked, statically or dynamically, to libX11 and friends; of course, barring the things written by masochists that implement the X Window protocol themselves over a TCP or Unix socket.
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:Who uses Xlib (Score:2)
Re:Who uses Xlib (Score:2)
I have used it on:
Pentium II 440LX chipset (Riva TNT)
Athlon XP SiS 730 chipset (GeForce2 MX)
Pentium 4 845M chipset (GeForce4 Go 440)
I don't use Xinerama or TV out very often.
Re:Who uses Xlib (Score:2)
just a data point for your consideration ^_~
Re:Who uses Xlib (Score:2)
Re:Erm... (Score:2)
I missed it too at first.
Re:Erm... (Score:2)
So it powers your whole desktop, and your whole desktop depends on it. But still it is very little used.
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:MODS: EXPLAIN (Score:2, Funny)
"DRM infringes on my freedom." +5 BORING!!!!!
Longhorn (Score:2)
Sort of like 'Quartz Extreme'? (Score:2)
What I can't wait for from OSX, Longhorn, and is an OpenGL/DirectX rendered display that also implements a vector-based system, so I can run my 19" display at maximum resolution and get finer, smoother text and widgets, n
Re:Sort of like 'Quartz Extreme'? (Score:2)
Re:Accelerated Desktop (Score:2, Informative)
Re:Accelerated Desktop (Score:2)
OS X uses GL only for window compositing!!! Its in Apple's Siggraph presentation! All drawing is done via Quartz 2D, which is rendered in software. Bit-blit acceleration is used for scrolls and drawing pixmaps.