Slashdot Mirror
The Power of X
An anonymous reader writes "The license changes in the last version of Xfree86 have caused many distributions to reject the project in favor of the forked X.Org X server. As X.Org prepares to release the second version of the X.Org "monolithic" X Server (dubbed version 6.8), Ars Technica investigates the future of the X platform, as cooperation between X.Org and projects like GNOME and KDE begin to take take hold at freedesktop.org. Already host to an impressive array of projects, it appears that freedesktop.org will become the hub in which other Free Desktop projects can collaborate. Daniel Stone, release manager for freedesktop.org, gets into the details on how it's all going to work, in conjunction with freedesktop.org's upcoming platform release."
I thought Xfree86 was a fork of the original X11 development camp and that X.org is a refounding of the original X11 camp after lots of splits, esp with alot of Xfree86 dev guys getting annoyed and going 'back to their roots' as it where..
Could be wrong (and frequently am)..
What I'd really like to see is some support for X type connections in the next version of windows. I don't mean basing all of windows on X11 but perhaps allow remote windows sessions that are native. Not based on screen redraws like VNC.
I know I'm going to get flamed by all the 80x24 textmoders out there, but compositing is cool
$ strings FTP.EXE | grep Copyright
@(#) Copyright (c) 1983 The Regents of the University of California.
With all this talk of X, ive remembered Y-Windows http://www.y-windows.org/ Does anybody know whats happened to Y? According to the road map, version 0.3 should have beed out 4 months ago.
He avoids answering the question about XFree86 Driver compatibility, especially with regard to NVidias binary drivers. This is a big issue for a lot of users and I hope that NVidias cards will be capable of using the new extensions.
As far as the article goes all I can read is that they work with both major graphiccards vendors but only ATI delivered so far. Or did I miss something?
One of the things that has always bothered me about XFree86 in the past 6 years I have used linux is XFree86's kind of lag in new releases... development seems to move at a snail's pace, and let's be frank, it's almost the same as it was back in the good ol' unix days.
I for one enjoy X.org and a windowing system that can hopefully be kept up to date and have more active development.
But my question is... how many more forks will we have?
James Carr
Its time a load of heads sat down and decided on the features that are required in the next MAJOR release of the X windows system/protocol. None of this piecemeal "we'll add it in as an extension" rubbish thats been happening for the last 10 years as this is becoming unmanageable; "My server has the dbe extension but not open-gl, your server has shapes but not etc etc etc." Just put ALL modern graphics requirements in the base protocol and write new extensions for Xlib and work from there.
I have not seen real dissatisfaction with the technical side of XFree86 in the last few years.
Have you been listening?
(A) There's apparently a ton of longstanding problems with the XFree codebase that are only now being addressed, both in fixing the current codebase and in a longer-term massive redesign/rewrite. The response for years has been "Well, it works..."
(B) There's been an emormous amount of criticism of X protocol design, going back 20 years. But with the rise of OSS frameworks, this reached a breaking point. The X response has been that the Toolkits serve the Windowing System and "Well, X11 is X11..."; rather than the more sensible attitude that the Windowing System should serve the Toolkits (and user programs). This is probably the biggest philosophical difference giving rise to the XFree fork.
The licence change was portrayed as a legal issue, but it was really just the final case of the "XFree Guys are Assholes". If the project wasn't already forking, there would have been no legal shit stirred up.
Please name an application in which compositing gives a better user interface ...
I worked in a GIS (geoprocessing) application to an electrical company. In the user's screen, a map showed up with all polls and wires that are in a location. If you clicked on a poll with, e.g., a transformer, a translucent (big) tooltip came up with all of the transformers specs, where the electricity was coming from, where it was going to, etc (like 20 lines of text). Without dismissing such tooltip, the user is capable of clicking in another poll in the map, and only the contents of the tooltip changed, (maybe it's position if it were possible to move "away" from the current part of the map. The user could even click thru the tooltip, in a poll that was showing below it! (there was a menu item/toolbar speed-button and a hot-key to close the tooltip, obviously)
This kind of interface is *very* practical and would be impossible without translucency. I implemented it in a no-nonsense 15 minutes under BorlandC++/w2k.
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
I just installed Slackware 10.0 and it came with the X.org system. I didn't even know about the change. I happily went into the config file and configed my video card, monitors, screen and all just like I used to with XFree86. After saving I started X like normal and all ran just fine.
I wasn't until I was reading later on that I realized there was a different X on my machine. Even then I was getting confused because much of Slackwares online docs have not been updated to refect this change.
I like X. X is good. Some X'es are better!
Where do you actually see the new eyecandy? Dropshadows, transparency, etc ... Don't new window managers and applications have to be built to take advantage of them? (I've only read part of the article, so sorry if I missed this answer there.)
Here's my take on it:
I use Linux on my systems (with Gnome as a DE) and I know what you mean some times. Part of the problem is that people write programs for different purposes - e.g. some people will write a program using Qt and the KDE libraries causing the programs to look one way, while somebody else will use Gtk or another toolkit.
It obviously isn't just down to the toolkit, but also depending on who the application is targetted at, most developers (generalising I know) don't have the time (or don't want to, or don't have lots of experience) to make their application pixel perfect.
Gnome has some usability guidelines and I think anybody would testify to the fact that Gnome itself and applications based around the HIGs have a very consistent feel. Likewise KDE has some HIGs (currently redrafting I think) but it doesn't have anywhere near the emphasis on the programs in the KDE collection IMO.
As well as defining the HIGs, part of the problem is to educate interface programmers and try to ask them to follow the guidelines - and more importantly, for people who have experience in usability (and that includes all users) to comment, suggest changes etc.
An interesting example was on the KDE Usability mailing list the other day - Celeste Paul posted a usability report on KHangman. The coder behind it appeared shortly after and immediately began following the conclusions of the report. I'm sure almost every programmer will be happy to accept constructive criticism for their work.
If you think a menu item or something isn't right, file a bug report against it - and try to include a suggestion (even if it isn't a complete solution) for how it could be improved. It only takes a few minutes. </rant>
This isn't a problem. All new functionality is done by extension to the old X11. I actually keep arguing that we should standardize an X12 which removes things not used much anymore and which includes (sans extensions) the functionality which is wanted, and provide and X11 interface for compatibility (if you have to make an extension extension because there are so many extensions, you need to move to the next version!). However, they don't want that; they want compatibility (which I don't hold to be orthogonal if things are done right, but I'm not (yet) and X hacker, merely an armchair X pundit. ;)
:)
Anyhow, rest assured that compatibility is top priority with these changes. You just won't be able to see the shinies.
--
Given enough personal experience, all stereotypes are shallow.
Sigh, there we go again...
First, get this: when you see a problem, there can be a whole bunch of causes. The only way to fix a problem is to correctly identify the cause.
Which you are not doing here. "X apps seem to be slower so X must be slow" may make sense from a non-technical user point of view, but that doesn't mean it's correct. In fact, it isn't.
If you benchmark things and stuff, you'll see that the problem is not in X itself: it's in the toolkits. So if people listened to you and ditched X, we'd still have the same problems because the toolkits are still slow.
Try using something like WindowMaker and some non-GTK non-QT apps. You'll find that they usually respond significantly faster (not on my machine though; Athlon 1.4 Ghz here, I don't find X apps slow).
And try playing 3D games. Look at the high framerate (assuming you're using a good card and driver, like NVidia + vendor drivers). How's that possible for a windowing system that's slow?
I've written several testing apps, for Windows and X. On both platforms, I get the same frame rate.
Expose events: Windows does pretty much the same thing. If I wrote an app that only responds to the paint event once, and I move a window above it, you'll see that the window won't be redrawn. Windows in fact uses the very same expose mechanism.
X *does* in fact have a feature which allows you to save the content of the window. It's saved Backing Store and Save Under (I think). QT and GTK don't use it except when popping up a menu. Ask the toolkit authors why they don't, because I don't know.
Data copying: data is *not* copied when transferring pixmaps, which is about 90-95% of the traffic. On localhost, XFree86/XOrg uses shared memory for that.
On localhost, normal X messages are transferred via unix domain sockets (not TCP sockets), which are almost as fast as shared memory (at least on Linux). Remember, this is small amount of data.
No modern windowing system allows the app to touch the hardware directly. Not Windows, not MacOS X, not BeOS. In fact, Windows internally uses the same message-based communication system as X. Windows apps don't draw directly to the hardware.
You can force it to use backing store by starting the X server with the +bs -wm options. According to Alan Cox this is better and feels snappier on most setups but will kill a tiny machine.