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!
still use non-bloated window managers like WindowMaker, Blackbox, IceWM, and Enlightenment that don't use the GTK/QT libraries.
Virtually every toolkit out there uses xlib. It really isn't
"little used", but rather key part of the whole *nix desktop.
... but having one group looking after all these libs would seem to offer some scope for optimisation and consolidation. Sounds like a good thing...
What's the DBUS ? (Desktop bus ?)
Simon
Physicists get Hadrons!
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.
XFree86 Has Not Merged With X.Org (see News)
[23 January 2004] http://www.xfree86.org/
So have they merged or not merged?
Is there any chance of this desktop being used on a distribution small enough for a credit card sized CD? 50MB.
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 may be better not as a separate library
XTrap
Xaw6
Xbsd
Xfontcache
Xft1 Maybe do not need this
Xinerama Multiscreen unified display
Xp X print
Xss X screen saver A newer smarter version of this may be nice
Xtst
XvMC?
Xxf86dga Probably does not need to be done.
Xxf86misc getting and setting of input device attributes possible ideas for better device handling
Xxf86rush
Xxf86vm VidMode? extension that allows modifying video attributes on the fly
apple
dps There may be a GNU package for this, but it may be old.
dpstk See dps
expat Should be depended upon
font
fontconfig
fontenc
freetype2 Should be depended upon
libxutil
libxml2 Should be depended upon
misc
oldX
psres See dps
regex
xkbfile
xkbui
zlib Should be depended upon
Saskboy's blog is good. 9 out of 10 dentists agree.
Don't forget to remove the line containing "killall X" in your crontab !
Bullshit.
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.
-
And the Angel said unto me, "These are the cries of the carrots! The cries of the carrots!"
One more question. Whats the diffrence between the freedesktop xlibs, and the xlibs in XFree86 ? I understand they forked from XFree at one point. What did they change/improve ?
I've used linux for years, but still get confused when people bring up this subject. I can't make heads or tails of all the different X's being bandied about. Half the time I can't tell if it's a group of people or a program.
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
Textbooks and Open Educational Resources
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.
And X is NOT slow.
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
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.
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...
Nothing happens when I issue the following command
/dev/fd.o /mnt/floppy
mount
Am I using this wrong?
microsoftword.mp3 - it doesn't care that they're not words...
Are the people at XFree86 maintaining xlibs also? Will this be imported back at XFree86? The release email says xlibs is actively maintained by fd.o (does this mean it is not actively maintained by xf86.org?), but does this mean fd.o will become the official version (i.e., the version bundled in the mainstream distros)? Or will they be two competing implementations?
IIRC, Debian already uses libXft from fd.o (which is a bit obvious, as Keith Packard is in fd.o).
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.
Meritless? It was a lot more amusing than the robotic cliches that modded up to +5.
"DRM infringes on my freedom." +5 BORING!!!!!
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 headline that got put on the press release was misleading. The reality is that X.Org has been reformed to be more like the GNOME Foundation. There will be open elections to appoint a board. Votes will no longer be obtained through monetary contributions; in other words, any one can have a vote and be elected, no matter their affiliation. The actual information handed out by X.Org should be posted on their site in the next few days, which includes the mission statement and aims of the project.
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
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.
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 new X screen saver just won't go away.
The window you're working in loses input focus. Permanently
-Don
Take a look and feel free: http://www.PieMenu.com
In 1988, I helped develop the NeWS driver for UniPress Emacs. James Gosling wrote UniPress's version of Emacs, as well as the NeWS window system itself. UniPress Emacs ran quite nicely on 4Sight. Emacs downloaded code to handle all the pop-up menus (pie menus or linear menus -- you could decide) and text selection feedback locally in the server.
After Emacs draws the text on the screen, it downloads a short array of numbers telling the server how many characters wide each line is, so the code running in the server knows just what it needs to give local text selection feedback.
So when you press down and drag to select text in emacs, the selection feedback is instantaneous even if you're running over a low speed dial-up connection. When you release the button or move the cursor outside of the scroll region, only then does it send a message back up to Emacs telling it to select the text, or initiate autoscroll.
How would you do that in X-Windows? Please explain your approach to extending the X-Windows server to support local text selection in emacs (and local pop-up menus while you're at it), without any unnecessary network traffic?
-Don
Take a look and feel free: http://www.PieMenu.com
It's a stupid graphical system that inverts the meaning of client and server. It needs a client (or is it server?) like XFree86 to run on your computer and display an ugly, useless black-and-white screen. It needs software like xterm to do anything with. It needs a window manager like TWM, FVWM or Metacity to actually move around windows. It needs a windowing system like KDE or GNOME to be presentable.
What it does by itself is anyone's guess. Probably low-level graphics calls.
What do you mean by "is"? "Should always be in every case"? Or "X-Windows has always forced us to do it this way"?
---
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 for round trips? Nope.
---
Probably not. But nobody is trying to remote X over a cell-phone link. However, X is quite usable over a low-bandwidth link, given an appropriate compression technology.
A NeWS-like architecture is much more efficient for implementing distributed applications on cell phones, because it permits the application to download executable code to the phone, saves the user time and money, as provides a high quality, responsive user interface.
---
Maybe, but cell-phone applications would necessarily have to be a lot-more limited than general-purpose desktop apps.
Have you ever heard of a language called "JavaScript"?
---
Yes.
In case you never heard of it, believe me: there are a lot of people willing to download JavaScript code.
---
If you can convince app developers to write their code in Javascript, than more power to you. But that's where I was getting at with the Lisp comment. To be really practical for modern desktop apps, you'd have to use something a lot faster than Javascript. For stuff like HTML rendering, there is a large computational bottleneck. Thus, you'd need a safe, yet fast language.
In case it's not obvious: The web browser / http server model IS a NeWS-like architecture.
---
To tell the truth, the web-browser, http-server model is working just fine on top of X. The needs of an internet-based system are very different from a local/network-based system, and I really see little advantage to a NeWS style system targeted at the markets X is aimed at.
The main problem with your HTML/Javascript example is that it only works well because all applications use the same basic display logic (HTML/CSS). However, desktop applications in general do *not* use the same basic display logic. The display logic of a text-editor is very different from the display-logic of a photo editor. If you want to implement this differing display logic in a NeWS-style system, you end up loading large amounts of complex display code into the server. And to feed that display logic, you end up shipping large amounts of data over the wire.
- additional ranting deleted -
---
There is no indication that X is holding back Linux on the desktop. What's holding back Linux on the desktop are ease of use and application support. X is quite competitive with the other two desktop systems out there (OS X's and Win XP's). With the freedesktop.org work, it'll be highly competitive with future UIs like Longhorn.
A deep unwavering belief is a sure sign you're missing something...
A C++ program can rely on a glib-based C library just as easily (perhaps somewhat easier, due to the consistent object model) as on any other C library. There is no problem here at all.
"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.