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.
Ah, there's probably a joke in there somewhere about crossroads and hidden treasure, but I can't find it...
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
I though he was working on all the termcap stuff...
What exactly are "the big issues"?
Low level xlib (ie, generic level) support for X session movement from machine to machine.
This sounds a bit like screen implimented for X - you can take apps to work and back again without shutting them down, and keep apps running whilst restarting an X server. (With a bit of luck it will support echoing one app to mutliple windows as well.) It also allows for graceful app shutdown when an X server dies.
Up until now I have been using VNC to do this, but adding it directly into xlib should make it a good deal less clunky. Way to go guys.
Beep beep.
I don't mean to X-Bash- leave that for xterm and Konsole- but I, for one, am ready to welcome our YWindows overlords, whenever they get here. I like the idea of rewriting from scratch once in a while, which is why I love the idea of scrapping X and going with Y. I mean, X is good, no doubt, but it shows its age. Transparent windows, more often than not, only show the underlying wallpaper and not the interlaying windows. Often, X just locks under load. Still, it is, under normal business circumstances, stable and functional.
#define DRM chmod 000
With the new X composition extention, all kdrive/xserver needs now is drivers. Snap snap is the solution. Without drivers you cant use the new x server, the new x server with a composite manager using openGL on paper is even better than what OSX offers. We need driver support.
People don't exist to serve systems, systems exist to serve people.
Sigh. And what issues are these? Have you talked to any of the X11 gurus lately, such as Keith Packard. I assure you they very much do "get it" and are doing wonderful things to make an already amazing framework even better. X11 is an amazing piece of work, one that is still working well today, almost 16 years after it was introduced. With the new extensions being worked on to allow compositing and true alpha channel blending, and because of the brilliant way in which is being done, the capacities of X11 can rival or even surpass Apple's Quartz system. No more nasty hacks are needed to simulate transparency. Everything from true live matrix transforms (imagine live windows morphing in real-time, something that even OS X fakes) to 3-d capabilities (the composite manager can map the live windows onto surfaces of polygons and use opengl to render them) without fundementally breaking the X11 protocol. In other words, remote log into an old SGI box and your apps will still run and have these effects.
Dispite all the work that's being done to make X11 better, it's number one killer feature has always been network transparency. Fortunately many of the security concerns of this are being addressed; X11 will probably soon no longer default to tcp/ip connections, but rather use unix-style sockets only and have ssh connect them. (Very few people have a real good reason to not tunnel X11 through ssh anyway).
So things are looking really good for the Linux desktop and X11. I'm excited for the next year and hope to be able to contribute in some small way. We have 2 years to really develop some great features before longhorn comes out. Hopefully with things like the composite extension, we can have more capabilities sooner.
For anyone that doesn't know:
The Xouvert Project
has been set up to help develop experimental extensions to X in an open way, using Free Software.
(It's not a competing X implementation, it is assistance).
(Jim didn't mention this in his paper)
Expert in software patents or patent law? Contribute to the ESP wiki!
Yes.
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
Reading this document has given me a new respect for the X developers.
You can use a modern X server to talk to an X client on a 1990s vintage machine with no problems at all, yet X is pretty fast on modern machines, has pretty good 3D support and is being updated to add more and more eye candy all the time - without breaking backwards compatibility.
Their aims may not be the same as the ones you think they should have for your own use, but when compared against their aims they are doing very well indeed, and should be recognised for that.
Beep beep.
We have 2 years to really develop some great features before longhorn comes out.
:(
Come on man, just take it for what it is. I'm not a part of your 'we' - I don't care about what other people are doing. I use X for certain things, and it works nicely. In the future it'll work better; great, but please don't put all of what you wrote in the context of just 'getting shit out before longhorn'
My students constantly complain and question why "windows" is in the name of a Unix graphical desktop program.
The phrase "windows," whether you choose to accept it or not, activates a subliminal correspondence to Microsoft's Windows operating system suit.
The X-Windows team should immediately begin to brainstorm possible new names for their project. Otherwise, it may never get off the ground entirely and could continue to falter as faster, real-time, 3-dimensional Open Source toolkits become commonplace (see KDE, Gnome, et al.)
"Windows" are bad.
Reply or e-mail; don't vaguely moderate. Ex-O'Reilly/MIT employee, now a full-time Google employee.
Back when I first got a PC capable of running X (1993?), I remember having to use Metro-X instead of XFree86. At the time I was blown away by Metro-X since: (a) it actually worked and was easy to configure -- no tweaking resource files all day, and (b) it seemed to cost money, which baffled me since I never figured anyone would pay for Linux software.
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!
1. What is channel blending?
2. What does x11 use matrix transforms for?
X, Fluxbox, RXVT, Bash. What more do you need?
Give me Classic Slashdot or give me death!
idiot
That's all nice and dandy. But how about a simple thing like the windows not flickering when getting moved/resized.
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.
BOSS Jim Gettys? As in, the corrupt politician with something less than a chance of being elected Governor over Charles Foster Kane???
I thougt he was fictional!
Install a video driver. Duh.
This is a very interesting article. The thing that I found most interesting is that it demonstrates that the open source community is now in the driver's seat with respect to X development. That's a real change from the old days when the X consortium wouldn't give the XFree86 group the time of day.
I know alot of people are down on the XFree86 group these days, but it looks like they single handedly destroyed the old X consortium.
"Very few people have a real good reason to not tunnel X11 through ssh anyway"
ssh, like lbxproxy and similar software adds significant latency to every operation to the point that our users made us take it out as the default, add to that the fact that on a multi-user server every single little bit of CPU power available is important. Encryption and compression are CPU intensive operations even a small increase in the load on a per process basis can significantly increase the overall load and reduce the number of concurrent users you can host on a box. That adds up to more money on more servers to handle the same number of users.
Basically, we tried ssh tunneling and while it's great on a small scale, i.e. individuals, it's a disaster for performance when hosting tens or hundreds of users, i.e. Linux in a corporate desktop environment.
Government of the people, by corporate executives, for corporate profits.
Ok, but can you deny that this is exactly what GPL is about? Forcing people to share their property. Just like under communism.
If my memory serves me correctly, this was several years ago already.
And what basically happened, is the XFree86 guys did a big "fuck you very much, we'll stick with X11R6.3".
The X Consortium, realizing they were no longer in the driver's seat, had to change their licensing so that XFree86 would go along, and it would appear like the Consortium still had authority.
If anyone else recalls the actual events better, please pipe up. But the take away message is that for all intents and purposes, XFree86 is X.
And Stallman is so rabid about his ideology that he often hurts his own cause.
not at all.
first you are an idiot about communism.
second of all you are an idiot about gpl software.
how is the : use at as you like it. forcing shared property?
and if you want to, you can even develop further and redistribute it. so options of software source code availability is some how forcing people?
dont like the license, dont use the code that someone else gracefully gives to you.
From the article:
"Both Qt and GTK+ in versions since late 1992 have used Xft2 for their text rendering."
I think it's time for the Y2K extension!
1) (partially linux specific) A way of getting DGA (or DGA2) to work for a non-root program. No sudo-stuff, no suid root, just a way for a completely ordinary user to use DGA without being able to crash the machine.
2) A standard way of getting an equivalent to the MSWindows Alt-tab and alt-enter for programs that run in fullscreen mode.
For example, an extension that the window manager can hook into, that allows fullscreen applications to run in an own workspace, and a xserver enforced keycombination that can bring back the window manager workspaces if the full screen application crashes.
NoMachine's NX compression system when talking about LBX or SSH compression. IIRC the core software is under the GPL.
:-)
I would have also liked to see a comparison to the other non-X systems people like to plug around here
All in all, I thought it was a pretty good summary.
They'll think I've lost control again and leave it all to evolution. -- Supreme Being, Time Bandits
Ok. I want to use it like this: I modify the source, compile the binaries, write them on a CD and start selling the disc.
The result: a rabid horde of GNUs on my front lawn.
Actually, if it was up to RMS, he would legislate exactly this into law.
We should all thank God it isn't.
We have 2 years to really develop some great features before longhorn comes out. Hopefully with things like the composite extension, we can have more capabilities sooner.
Unfortunately, this is why Linux will fail. It's trying to beat Microsoft instead of just innovating.
"Sufferin' succotash."
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.
There is no such thing as an "X desktop", just like there is no such thing as a "GDI+ desktop" or a "PDF desktop". X is a low-level protocol.
Whether a desktop based on X is easy or difficult to learn depends entirely on the desktop. Something like Ion or CDE, can be frustrating, unintuitive, and complex to novices. OTOH, your local ATM, which may be running X as well, probably is so easy to learn that you don't even think of it as "learning".
Why should I care what RMS likes or dislikes? I'm not saying this to be mean, since I think RMS is a very smart and dedicated guy. But I hope most people can form an opinion about a software project without needing to defer to RMS.
I have no problem with GPL. I have a problem with the zealots re-defining what's free and what's not.
If I cannot do anything I want to with the source code it is not free. Period. Otherwise it is restricted and therefore not free.
Here's an experiment for you.
Get a server that's fairly busy.
Run a tunneled X app, and I don't mean xclock or xload.
Then run the same app without tunneling.
Report back if you still believe there is no place for non-ssh tunneled connections.
ssh tunneling is wonderful if you don't have a secure channel. If you do though, it's a whole different ballgame.
cheers.
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.
Zoo-vaire.
From: http://www.xouvert.org/
Ouvert is French for open.
It's unfortunate this word in the context of computing or GUIs doesn't also trigger the memory of a trademark dispute between Microsoft and Lindows. In this case, Microsoft lost and subsequently urged anyone referring to any version of their proprietary operating system (or the MS-DOS application) to call it by a more descriptive non-generic name. It's interesting to note Judge Coughenour's logic in denying Microsoft a preliminary injunction in this case:
But this story mainly serves to reinforce the value of repetition--in the aforementioned lawsuit, and as a professor who probably gives lectures, you probably already understand the value of repeating something you want to stick in people's minds. The reason people don't recall the trademark dispute is because few people heard of it. If we are to get people to use the word "windows" to mean something else (perhaps a general term that immediately makes them question the ambiguity) we must persist in repeating explanations and recent history. Widespread repetition is one way people learn new meanings (just as they learned "windows" in the computer sense as a colloquial synonym for "Microsoft Windows" and for the visual object one can drag around in a GUI).
Digital Citizen
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.
But the take away message is that for all intents and purposes, XFree86 is X.
No, it isn't. X is a protocol and a standard, XFree86 is an implementation. What has happened is that the developers of XFree86 have become so influential that they, rather than the X consortium, set the agenda. But the X standard is, and continues to be, implemented by many different vendors and projects. It would be a sad day when X became synonymous with the XFree86 implementation.
OS X is not OS/X
I've tried to find a way to make screen rotation work with any generic video card so I can put my monitor in portrait mode. I had a lot of trouble making any sense from the goobleygook I found on Google, as near as I can tell rotation is still basically a dream. Can anyone shed light on this?
X can be improved but doesn't need to be rewritten
Did I miss something?
cLive ;-)
-1 Flaimbait :)
-- Trinity in high heels carrying a whip: The donimatrix - there is no spoonerism
It's all part of the deal. Read the docs at www.freedesktop.org and you'll see how the composite extensions now only can give you special effects, but allow for smoother redraws, due to the buffering that's now possible. A lot of flicker in the past has resulted from redraws. The XDamage extension can now drastically minimize this, as I understand it, but double-buffering using a composite manager will dramatically improve things as redraws are practically eliminated for things like expose events.
Right... except for all this happened back in 1998.
The roots of education are bitter, but the fruit is sweet.
--Aristotle
so you have a problem with taking someone elses work and not be allowed to do whatever you like with it.
you want to take but not give. well guess what, those developers own that code, they ownly give it to you because they want to. so if you dont like the rules, get out of the game and write your own code for that cd you want to sell.
so you arguement is this: "i modify windows 2K by changing the installer, then start selling the CD"
the result, i have microsoft lawyers on my front lawn
you are a real idiot. and dont worry about your hypothetical situation, you cant program anyways.
Just found this comparison of "The Other Window Managers". It's an interesting read.
That article is about XFree86, not X11. The freedesktop.org X server is a different X server than XFree86, yet it appears to me that it will eventually replace XFree.
You are a one note song that nobody cares about. Why do you keep harping on the same old discredited ideas? Are you really that stupid?
Yeah, I know: IHBT, IHL, HAND. Happy?
thanks for correcting me.
Sigh. It's not X Windows. Never has been, never will be. It's a window system called X, or it's X11R6, or X11, or X, or The X Window System.
-russ
Don't piss off The Angry Economist
never achieved widespread acceptance (as in the X Color management part of the API)
Perhaps that never achieve widespread acceptance because the XFree86 implementation (or perhaps just every graphics card I ever tried it on) sucked big time.
I wasted far too many hours trying to implement some things using this (that I'd done before with commercial X implementations on dedicated Unix hardware) before giving up in disgust because it just couldn't be done.
What kind of things? Stuff like a vector graphics program where the selected object(s) blink by repainting them in "blinking ink" -- a designated color number whose colormap entry is regularly toggled by another process. Or doing vector-over-raster by selectively allocating and masking the pixel planes.
Yeah, there are other ways to do it, but it's just so much easier with the access to colormaps and different (eg PseudoColor) visuals.
-- Alastair
Okay, I may be unique in that I still do some open source development with Motif (mostly wrapped in C++ classes...), but he also calls the Tk toolkit obsolete.
Eh? Perl/Tk, Python/Tk and (let us not forget) Tcl/Tk are obsolete? Not dead yet, I'd say, although perhaps GTK+ is starting to replace it in favor. What say you?
(And I guess I can finally throw out my old PEXlib and OpenLook books. Sigh. Anyone got a graphics API they want rendered obsolete? I'll just go study up on it, that should do it...)
-- Alastair
XF86 is one of the worst ones and most bloated X's out there. Its hard to write drivers and modules for according to alot of hackers ( I do not write X specific code and can not comment myself).
I think if early workstations had no trouble with X, then it should stay and only the implementation be rewritten.
I would also like things like better refresh rates and DPMS support. I can never get my screen to look as good in X then in Windows with the proper refresh rates. Yes I know the correct vertical and horizontal modes.
That is never a problem with the X's on standard Unix's like Solaris.
http://saveie6.com/
You are talking about Colormaps, while the paper is talking about the CMS (color management) stuff added to the X standard. The CMS stuff was never used, and was a totally stupid idea. Color management should be done by the program, and any system where the 8-bit number chosen by the program does not end up in the image buffer means that true color management is actually impossible, completley reversing the whole purpose of this extension.
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. On older hardware there are obvious alternatives so that the interface could look like true-color, such as using a fixed color cube.
Colormaps were a serious detriment to advancement of graphics. Sun was forced to add several bits to each pixel of their full-color display just to store "which color map" because of the need to support legacy X programs that assummed there was a colormap. At least now most programs that required colormaps are gone, mostly due to the fact that XFree86 did not support them.
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
Who are you referring to exactly? If Keith Packard, well he is about the only person who is actively working on improving X internals, he's already given us Xft, Xft2, XRender, Kdrive (which is /very/ promising). He appears now to be working on 2 extensions to allow X to do compositing. To call him arrogant or narcisstic to ask for CVS access is plain wrong.
/lot/.
Further, he appears to have the support of Jim Gettys, which says a
I use Friend/Foe + mod-point modifiers as a karma/reputation system.
http://developers.slashdot.org/article.pl?sid=03/1 0/27/1818256&mode=thread&tid=104&tid=185&tid=1 89
3 28 .html
http://cygwin.com/ml/cygwin-xfree/2003-10/msg00
-- Trinity in high heels carrying a whip: The donimatrix - there is no spoonerism
Ah, sorry, you were referring to the XFree people who deny access as being narcissistic, sorry :), and yeah, they seem to be (from what little i know.)
I use Friend/Foe + mod-point modifiers as a karma/reputation system.
You are seriously deluded about how much computing power is needed to change the pixels on the screen. A typical game now is changing the color of EVERY SINGLE PIXEL, up to 80 TIMES A SECOND, and is doing a much more complicated operation that just filling a shape with a constant.
Also it should be obvious that any of the symbolic graphics you are talking about can be drawn on a full-color display. The fact that many pixels have the same color does not mean that a colormap is required.
I have programmed with colormaps with cells reserved for "blink". I have also used sprites and overlay planes. Yes I can see why these were created, but I can also state with absolute conviction that I am glad they are gone.
The only reason Colormaps survived so long in X is because of the absurd design so that a colormapped machine could not pretend to be full-color. Windows (much to Unix's embarassment) at least made the true-color calls work and produce ugly dithering on colormapped displays. The result was that every program was rewritten quickly to not require colormaps because it was so vastly easier to use the true-color settings, and it soon became far more likely to find a full-color display used on Windows than on X. It was not until XFree86 with it's one-visual-only design that Linux displays caught up.
All very clever and it sounds like he knows what he is talking about.
However perhaps he should examing exactly how those new-fangled high-speed hardware boards work. Maybe examine how geometry is sent to them nowadays. Take a look at how those fragment/pixel shaders are stored and sent to the card. Take a look at how they get operations to happen on vertical retrace.
Hint: it looks a LOT like a stream. And this is designed by people who are desperate to get them to run as fast as possible.
You might also check why disk interfaces are going serial, and even the main bus may go serial someday.
"*bufferptr++ = x" is faster than any call, and can be easily parallelized. Also memcpy is much, much faster when you have a block of already-composed graphics. And if you studied it at all you would see that at least 90% of the operations a program do is "copy this precomposed graphic (which could be a letter or glyph) from memory to the device".
Chill. It's a sign of affection and familiarity that people have gotten sloppy with the name. When you complain about it you sound like the easily offended Mac fans who object to "TiBook" for the metal cased PowerBooks. Some of the people you're bitching at are the system's biggest fans. "X Windows" manages to uniquely identify the system, it's widely accepted in the appropriate circles.
Search 2010 Gen Con events
YesTool, a GUI interface to the classic powerful Unix utility " yes ", written by the great hacker and University of Maryland alumni David MacKenzie!
YesTool will be totally user configable, just like the permissive command-line " yes ". It will be written in object oriented reusable code using parameterizable C++ templates, so you can easily subclass it to make your own tools like NoTool, MaybeTool and ExecutiveDecisionMakerTool. It will support drag-and-drop in single-answer or streaming mode. Also an emacs support package is in the works, with a special command called "psychoanalyze-yes"! And of course it will support gestures, and video input so you can nod and shake your head.
For more information on " yes ", type "man yes". If you don't have enough men in your life, type "yes man".
I've written up a design spec in Star Open Office, made some concept screen mock-ups in Gimp, hacked up a prototype in GTK-Perl, but I still just can't seem to get drag-and-drop to work on X-Windows. I'm going to put the prototype up on SourceForge so everyone else can contribute, as soon as I can figure out how to get the damn autoconf file to work.
-Don
Take a look and feel free: http://www.PieMenu.com
x windows, more like x winBLOWS
Jim's wording is ironic because Adobe's SVG viewer used to work in Mozilla on Linux, but not it no longer works, in post-0.99 version of Mozilla. Not because Adobe broke it, but because they trusted Mozilla enough to use one of their "unsupported" XP-COM interfaces, which Mozilla changed. [See Mozilla bug number 133567.]
Granted, Mozilla had warned Adobe that they might change the interfaces, which were not yet frozen. But Mozilla broke their side of the contract by neglecting to change the UUID of the interface, when they changed a method signature, which should be Standard Operating Procedure.
The whole point of using XP-COM (which is the COM-like plug-in system that Mozilla uses) is to protect against things like this happening. But Mozilla didn't play by the rules, and screwed Adobe after they'd already released their SVG viewer plug-in.
So everyone is screwed because Adobe's SVG viewer USED to run on Mozilla on Linux and Windows, but NOT ANY MORE. Mozilla's built-in SVG support is impressive and commendable and going in the right direction, but nowhere near enough to fill the void left behind when AdobeSVG just stopped working one day.
Mozilla moved the bug that ASVG crashes mozilla to "Evangelism", so now the ball's in Adobe's court to decide if they'll trust the Mozilla project again after having been burnt. Of course it was the Mozilla project's Overenthusiastic Evangelism that convinced Adobe to use the early plug-in interface in the first place. You have to appreciate the irony of fighting fire with fire.
In the perfect world, Adobe would have released a fix for this problem soon after the it was "Evangelized" to their attention. And I would like a pony with that. But in the real world, they're off on the next version of their SVG viewer, and don't want to think about the old version. You can get a beta of the new version for Windows, but it's unstable, and not supported on any other platform than Windows.
But if you're using Linux and want to use Adobe's SVG viewer, you have to sit around and wait, hoping that Adobe will get around to releasing the next version of their SVG viewer, and when they do it will support Linux. But there are no guarentees. The original SVG viewer for Linux was only released as beta, never officially released. And Adobe's been said to be back-pedaling on SVG and concentrating on other products.
Batik would be usable as an SVG viewer plug-in (not as efficient but almost as functional where it counts), but I haven't been able to get past the Java security restrictions to enable the emcascript interpreter (rhino). Batik packaged as an SVG viewer browser applet (in a way that rhino worked, enabling dynamic svg) would go a long way towards rendering Adobe's proprietary SVG viewer irrelevant. But I haven't been able to figure out how to get rhino to work in an applet, or find any examples of Batik running in an applet as an interactive SVG viewer. Squiggle is not what I mean by an applet.
-Don
Take a look and feel free: http://www.PieMenu.com
There is absolutely no need for a new window system to be backwards compatible with X in any way at all. Just run an X server in a window. Seal it off into its own minor sub-process, and don't let it pollute the design of another window system.
Compared to what? There are hardly any X apps out there, compared to the number of Windows apps. Most of the X apps out there have sucky user interfaces, or are trivial, or use a toolkit that's portable anyway. Don't let xcalc hold you back from doing something new.-Don
Take a look and feel free: http://www.PieMenu.com
(It's about the XIE image processing extension, but I think it's a great summary of the whole X-Windows situation.)
My second favorite quote is about the so-called Security extension:
It is not clear at this date whether security serves any useful purpose in today's environments.What's not to hate? Pass the hexkey and the MIT-MAGIC-COOKIE-1!
X-Windows: Even your dog won't like it.
-Don
Take a look and feel free: http://www.PieMenu.com
There are many, many, *many* people out there who flame down X for "copying of MS Windows". They even think MS can sue X just because they think X is called "X Windows".
But why? X is not called "X Windows". Yet people still flame down for something X isn't, just because everybody calls it "X Windows".
This misunderstanding is taking rediculous forms. It's starting to harm X.
Let's compare it to this (example) situation:
You wrote a book called "21st Century Car Engines". There is already another (popular) book called "Cars" written by Joe. Everybody calls your book "21 Cars" even though that's not really your book's name. You try to tell them about that but they don't listen.
The next day, your mailbox is suddenly filled with hundreds of hate mails, accusing you of copying Joe's book's title, just because everybody *thinks* your book is called "21 Cars", while it isn't.
Won't you get pissed at that? Everybody hates you now because of something that isn't even true? Won't you get annoyed at that?
And that's still a primary use of windowing systems for a lot of people today. Also remember that MS Windows wasn't really usable until 1992 with version 3.1. I was working with PCs through that entire period, and although I was vaguely aware that MS did have a product called Windows, and in fact I had tried some of the earlier versions myself, they were completely useless. Whereas X on Unix, for those that were lucky enough to rate a Workstation, was very slick and usable in '92, windows 3.1 was barely usable for a few things, and so often getting things done under it involved exiting back to DOS that we made a conscious decision to stick to DOS alone on most machines.
I don't believe I ever heard anyone call it 'X-Windows' until well after '92, and I believe it was on the model of MS-Windows by people who were familiar with that first. This being the case, it makes sense that the X consortium wouldn't like that usage - first because it's simply not the right name, and second because it does seem to have it's origin in a confusion with MS Windows.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
Alright, Gentoo's portage package management does this to a certain extent, if I want to know what purpose package 'samba' is I can just 'emerge -s samba' and it will tell me "net-fs/samba - a native windows file server"
/usr/portage/net-fs' and get a listing of other network filesystem utilities there are.
If I want to see what other packages are in that group I can just 'ls
"Sometimes, I think Trent just needs a cup of hot chocolate and a blankie." -Tori Amos on Nine Inch Nails
You are seriously deluded about how much computing power is needed to change the pixels on the screen.
Not at all. Just that it's more power than is needed to toggle a value in a LUT.
A typical game now is changing the color of EVERY SINGLE PIXEL, up to 80 TIMES A SECOND, and is doing a much more complicated operation that just filling a shape with a constant.
Sure, and it's doing quite a bit of that in the graphics hardware (GPU), not the CPU. And very little of that ever has to go over a network (the big advantage of X, remember?).
Also it should be obvious that any of the symbolic graphics you are talking about can be drawn on a full-color display. The fact that many pixels have the same color does not mean that a colormap is required.
Of course, as I said in my earlier message. Programmatically, though, it's a pain in the butt. If the card manufactures want to simulate colormaps this way, that'd be fine. Or even if the XFree86 folks had decided to emulate them in software to make X Visuals work on hardware that didn't support them, that'd be great too. If I've got to emulate it myself, its a truckload of programming that I shouldn't have to do given the X definition.
Basically I have to maintain my own image buffer, and either emulate X writes to it or blt the pixels from the X server to keep it in synch, manipulate the pixels myself, then blt the whole thing back to the X server. Bleah! What kind of crap is that?
The only reason Colormaps survived so long in X is because of the absurd design so that a colormapped machine could not pretend to be full-color.
This was correct behaviour. Method, not policy. If the hardware couldn't support truecolor it was up to the program to deal with appropriately, not for X to guess at it. But colormaps and truecolor are not mutually exclusive.
Windows (much to Unix's embarassment) at least made the true-color calls work and produce ugly dithering on colormapped displays.
Thereby guaranteeing that there were plenty of incorrect pixels without letting the application know about it. Perhaps X should have implemented this as an option (plenty of apps that don't care if every pixel is perfect) but with some apps you really do care if a pixel is illuminated to a value because it really represents something or just because it happened to dither to that value.
The result was that every program was rewritten quickly to not require colormaps because it was so vastly easier to use the true-color settings,
What in the world are you talking about? "every" program? Games and paint programs perhaps. Ever done anything with serious visual analysis of real-world data?
It was not until XFree86 with it's one-visual-only design that Linux displays caught up.
Actually XFree86 pretends to support multiple visuals (currently on my Matrox card it's reporting 8, 4 TrueColor and 4 DirectColor) but the implementation is broken. Which is what really sucks. If it just reported a single visual available, a program would know not to even try messing with visuals. Instead it reports them there but ignores colormap changes. The program lies about its capabilties.
-- Alastair
It wasn't about the licence for X windows.
How about it being virtually im-fucking-possible to do things such as make fonts look good that take 2 seconds in Windows yet require lifetime study in X? I've managed to get anti-aliased fonts working in the past but I have no fucking clue how I finally managed to do it, not to mention more stupid things like half my apps not using them, granted that's not necessarily X's fault, but I can't imagine what kind of nightmare programmers must have to go through to make X work if it's impossible to configure from a user's perspective.
Also might I add that this is a MAJOR issue with Linux and free software apps in general. Developers love to add new fancy features like matrix transformations and alpha blending and so on but none of them seem to want to make anything usable. If you want Linux to remain the domain of Unix geeks, that's perfectly fine, but if you want it to be used by a wider population something has to be done to make these things workable. Even I, as a moderate Unix geek, don't like screwing with these things to the point that I don't bother with free operating systems and just use free software on Windows when I can, I mean it was interesting the first time, but when I have to make ritual sacrifices to the X God every time I want anti-aliased fonts on a new install I'll pass. By all means, make it look good, but don't introduce uber-bloat and configuration hell while you're at it.
Actually XFree86 pretends to support multiple visuals (currently on my Matrox card it's reporting 8, 4 TrueColor and 4 DirectColor) but the implementation is broken
The direct color visual is because the card supports per-channel lookup tables (ie a 256-entry table for red, another for green, and another for blue). The only practical use for this is for gamma adjustment, but most hardware is broken in that it only supports 8-bit entries in the table, making any setting other than the identity useless because at least 2 colors will map to the same value. As you probably know, such tables are useless for "blinking pixels" or any other use. Once upon a time they were used for fast preview of color corrections, which is similar to what you are requesting, but that is not usable for modern painting programs where most corrections are not color-independent and thus the programmers time is better served figuring out how to update the whole picture directly than to try to use this, also most users are annoyed when the entire GUI changes color when adjusting their photo's correction.
The reason TrueColor is reported as well as DirectColor is because of programs that only look for TrueColor. On XFree86 if you mess with the DirectColor lookup table you will also change the TrueColor lookup, which is not what the design of X intended.
Again I feel X's design is just WRONG. It could report *only* TrueColor, and have a seperate call for "change the color lookup" which could also accept an arbitrary-sized set of points that it interpolates, so you don't need to know how many bits per pixel are stored. This call could return failure if the hardware cannot do it.
The reason there are 4 of each visual is for GLX. Due, again, to stupid design, the only method of communicating how a window was set up from GLX is to change the visual number, so GLX needs to use this to send what buffers are enabled to X. Most likely these visuals correspond to whether a back buffer is enabled and whether an alpha buffer is enabled, on my Irix machine there are 64 copies of each visual, indicating 8 on/off selectors. Again all obsolete on modern machines, where it would probably be most efficient to turn on all buffers all the time.
I have to thank you. This discussion over the last couple of days led me to take another look at some code from a couple of years ago where I'd been thrashing over getting pseudocolor to work right.
:1). And colormaps are still are PITA in DirectColor mode (whole screen colormap changes depending on the visual of the active window -- as you alluded to above).
And you know what? PseudoColor (and DirectColor) does work in XFree86. I'm going to give myself the benefit of the doubt and say that a change of video card and a couple of releases of XFree86 made the difference. (The original version of the code is long gone, so I'll never know for sure.) I can now draw in blinking ink (and I may just add three-way color cycling to simulate motion, as in flow direction along a path (pipe, etc) for example).
Oh, yeah, you have to create the X Server instance with the appropriate depth to magically get the set of visuals you need (fortunately with Linux's virtual consoles I can have multiple X servers running multiple virtual displays simultaneously -- although KDE and Gnome get confused if you try to run more than one copy of either at time (so I just run twm on display
I think we both agree that the design (API) is fundamentally broken, we just disagree on the usefulness of dynamic colormaps.
-- Alastair
I'm not upset about the fact that people call it X Windows. I'm upset about the fact that somebody would criticize the X11 folks for naming it "X Windows" when they never did that.
-russ
Don't piss off The Angry Economist
-Don
Take a look and feel free: http://www.PieMenu.com