Slashdot Mirror
New X Roadmap from Jim Gettys
A reader points to a roadmap on freedesktop.org that provides a good summary of what is out there for *nix desktops, with emphasis on X but also covering some other areas.
← Back to Stories (view on slashdot.org)
...through controlled marketing. The learning curve of Linux aside, people can be sold on the idea of Linux en masse. There are video games that take longer to learn than basic control over the X desktop.
Except a long list of associated technologies. For a non X-pert, the article is just a summary of what is there out there. I was expecting some sort of "this is what the future plans are."
Roadmap is a little bit misleading term.
S
A very good overview of the major tools used on Linux desktops.
I've been wondering about menus in Linux/*BSD - not so much the format of menu storage, although that is an issue, but the applications themselves. We have a very large number of applications out there, but that is a problem for end users because installing them does not result in an update of the graphical menus by which they tend to access them. I think this is one of those little things that makes people think Linux isn't desktop ready.
I've been wondering - why not do something like the following:
Create a database of all applications which are or might be deployed on Linux boxes. Define a standard, detailed menu structure into which all these should fit. For example, in the case of science/mathematical applications:
(Sci/Math)
(Math)
(Symbolic)
(Numerical)
(Plotting)
(2D)
(3D)
(Electrical)
(Layout)
(Simulation)
(Chemistry)
(Drawing)
(Simulating)
(Physics)
(Mechanical)
(Electrical)
(Quantum)
(Misc)
Categories exist mainly as examples - they are not suggestions for what they would actually be. Do the same for graphical applications, editors, programming tools, etc, etc, etc. Once the structure is layed out in broad, start with the Debian archives, freshmeat, sf and savannah, and the other usual suspects and begin defining entries for each application. For each app, there will be a category or categories into which they fit - define this in the entry. To avoid duplicates, assign each category ranking a numerical value - 1 if it definitely should be there, two if it works there but someone wanting a smaller menu structure might not want it, etc. down to don't include this unless a full menu tree is specified. Allow arbitary execution techniques, so apps needing options or odd ways of launching can be accomidated.
Then, have a way to scan the system binary directories and update based on new binaries found. If the app needs options defined when starting, the entry in the menu will know that and prompt for them when adding it to the active list. Perhaps with some kind of tripwire style system monitoring the menu system could even be triggered as a new binary appears.
This system would be general and independant, because anybody could write a utility to generate a system's menus based on the database. Then, also, there can be global levels of configuration available. The user could define their own sensitivity - say "Show all Graphics programs but only show level 2 or better text editors". There can even be a "standard" menu structure that doesn't use app names at all, but only generic names and uses the highest ranked app in each category.
Does anyone know of a project like this underway? I know people have made lists of apps before but if a protocal could be defined to add things like a central database, updating based on binary appearance, user configured options as program is added to menu if desired, etc it might really cause a revolution in Linux desktop menus.
"I object to doing things that computers can do." -- Olin Shivers, lispers.org
Any X "roadmap" is going to have the hungry trolls out in force, mindlessly flailing around with "arguments" that X is badly designed and should be junked at the first opportunity.
My take is this. You can do what you like to the underlying graphics subsystem. I neither know nor care what the protocol-on-the-wire says. However, you can take the network transparency from my cold and bloody fingers once I've shuffled off this mortal coil, and even then you'll have a fight on your hands. This single attribute is the reason I use it, and why it's possible to remotely administer far far more unix machines than windows ones. VNC is cool, but X is built-in. I love it.
Simon.
Physicists get Hadrons!
It isn't.
It's called "The X Window System."
Or simply "X".
"X Windows" is a misnomer.
My posts don't reflect the opinion of my employer, and my employer's opinion doesn't influence the content of my posts.
This is a joke, right ? Time to get new students if not...
Just in case...
"get off the ground" ? Like, oh to pull an example out of the air, running the only graphical user interface common to every computer platform I've ever used ? It runs on just about everything it is possible to get a framebuffer on - I've even used it on an Atari ST....
"get off the ground." HAH!
Simon.
Physicists get Hadrons!
You're basically saying "don't trust anything that isn't copylefted." I'm sure most of us use BSD and X/MIT and similarly licensed software with no qualms about it whatsoever. The problem documented on that page was with the X consortium and Open Group. If you're afraid that the XFree people or the freedesktop.org people are going to take the code and make it non-free, then you're insane. If you're OK with being insane, then checkout CVS reguarly, and if they decide to make it non-free, you can just make your own free fork, or whatever.
What the hell are Blackbox Lite and NVM?
And I find this hilarious:
Uninstall X immediately
(Score:1, Insightful)
Hah! Better find every non-GPL piece of software and uninstall it too.
All that stuff is great, but the clipboard situation still stinks. It's one of the main stumbling blocks whenever I try to get someone interested in using Linux.
Even if you truly believe in selection/middle-mouse, you have to admit that it should at least be *possible* to configure X to use a universal Alt-C/Alt-P.
Heh, and now it seems the roles are reversed. XFree86 is a dinosaur, and all of the interesting stuff is happening at freedesktop.org. Funny how things change over time.
Given how much computers have changed since X was released, it is amazing they've kept this level of backward compatibility. As the Unix desktop matures, this will become more important than ever. Contrary to what vendors want you to believe, it's not necessary to upgrade everything every 6 months.
First off, you're an idiot. The GPL in no way means that the software has to be made available free of charge. The GPL simply states that if the software is made available in binary form, the source code has to be freely available as well.
Second, I view the open source development process as much more akin to capitalism than the traditional proprietary development model is. At, say, Microsoft, you have project coordinators who say "okay, you do this, you do this, and you do this." The open-source development model is much more capitalistic in that if you find an area that can use improvement, i.e. a faster algorithm for something, you upload a diff to the CVS server and it gets integrated into the source tree. In this way, the programs are competitive not only with one another, but with themselves as well.
VNC doesn't work at the individual application level; this does. That makes an enormous difference.
You can get some idea of how this will work in XEmacs (which has multi-display support and can be moved from the console). There is also the xmove server, which already implements this functionality via a proxy.
It's amazing that this has taken so long. The members of the X Consortium have really been sitting on their hands: this functionality was intended to be in X11 since pretty much the beginning.
Note that network transparency is really mostly about conventions and standards for applications running on different hosts.
VNC doesn't try to address that issue at all. And, in fact, GDI+ and Quartz can be trivially used as remote display engines, but neither their toolkits nor their applications have any clue how to behave properly.
Unfortunately, Gnome and KDE are eroding network transparency in X11. For example, they use some of their own preferences files, accessed via the file system, which means that preferences come from the remote machine, not the desktop. I think Gnome is trying to address this, I'm not sure about KDE.
Robert Stallman recently published a treatise entitled "The X Window's Trap" on his GNU.org personal homepage.
Stallman (that's Richard Stallman) in that article makes a point about the X Consortium's licensing policies. The X Consortium, in fact, took a position similar to Microsoft: "open source is good only if we can take the source and make it proprietary whenever we like". That's what Stallman disagrees with.
We can't say "Fuck Bill Gates" in one breath and then "I love X" in the other and remain morally sound and forthwith.
You are right if by "X", you mean "the X Consortium". But the X Consortium has been pretty widely disliked in the open source community for a long time for just that reason.
X11 itself, however, is an open network protocol. Stallman doesn't have any objections to open network protocols.
I think it's much more common to use *almost* all text-based apps. Every window I have open is an xterm, except firebird. I also use gimp sometimes, nicotine, and maybe a couple other gui apps once in a while. But browsing is the big one. Pretty much every browser sucks IMO, and firebird is the closest to not sucking. Text browsers are definitely not my cup of tea (nor is elinks running in framebuffer or whatever).
:) In console you're fairly limited to how you can navigate and view things.
So I make the decision that using X is a good idea. I don't understand why that means you'd automatically want to use all GUI apps along with it.
And even if I only used text-based apps, X is still nice, because I just like a windowed GUI. I like being able to move and resize windows, and manipulate them in whichever way I want. I like being able to use the keyboard for directional focus and viewport switching, and at the same time, i can lean back and surf with the mouse and flip viewports with that too by clicking on the screen edge. Stuff like that. Must be why I work on a window manager.
You are talking about Colormaps, while the paper is talking about the CMS (color management) stuff added to the X standard
Ooh. Never mind.
Colormaps and Visuals were (and still are) a serious error in X. They have no place in modern graphics and make it very difficult to get a desired color.
Actually, I take that "never mind" back. You seem to be defining "modern graphics" as that subset of computer display graphics that concerns itself with making images and graphic layouts look "correct" so that what you see on the screen is what you'll get on the page when it's printed (or TV or theatre screen when it's rendered to media for those).
Like I said, that's a subset of what people use graphic computer displays for. Aside from the pretty picture industry, the computer display is a communication tool to present information in the computer to a human user in the most rapidly undestandable manner. An air traffic controller doesn't want photorealistic pictures of aircraft flitting over the screen, that's too distracting, he just wants a symbolic representation of the specific information he's interested in. A GIS analyst doesn't care if the mixed raster and vector image he's looking at matches what the ground outside really looks like, or even what a printed copy would look like (and while a cartographer might care about the latter, he's only going to want to use a small color palette). The GIS guy does care if the 4,327 features his query selected are going to highlight quickly, and whether or not he'll be able to distinguish them from the various other colored features on the display (this is the advantage of blinking).
Colormaps were a serious detriment to advancement of graphics.
Your particular branch of graphics, perhaps, but not that of countless others. Changing a colormap value can be simulated by redrawing all the relevant pixels in a different color, but at what a senseless waste of CPU cycles and memory bandwidth.
Sun was forced to add several bits to each pixel of their full-color display just to store "which color map"
A nicer approach than just letting the windows with a different color map look strange, but not the only way they could have done it. But bits are cheap. Another megabyte of RAM? BFD.
most programs that required colormaps are gone, mostly due to the fact that XFree86 did not support them.
Not gone, not by a long shot. Just not ported to Linux, at least not without requiring a commercial X11 package.
-- Alastair
Just to be technical, pure "latency" is not the problem with X. You would be suprised at how easily you could use a machine where the display updated fast, but was delayed 1 second from anything you did. Shooting games might be difficult, but a lot of bad word form-filling software and the web work this way.
The round-trips are made bad by latency, but the real problem is that they require 2 whole latency steps for every call. Even a microsecond makes the display draw unbearably slow. Non-round-trip calls can be shoved down a pipe and thus hundreds of thousands can be sent in a second even if there is a second of "latency".
Even making a "DRI" interface, as is often suggested, will not help, as it still means a good number of machine instructions, pushing and popping, are done each call. Some misguided other posters seem to thing "marshalling" and "unmarshalling" are expensive, they are wrong. Ever wonder why things like "display lists" are used to make 3D hardware run fast?