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.

X Can Be Sold...

...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.

Re:X Can Be Sold...

The difference (and this is not a slam towards X - I love it) is that learning a video game is a recreational process. Learning X in a business setting is a productivity issue. In many cases this isn't a big deal, but in some situations this can be a serious consideration. When you have to take time for employee training the benefits of an X system may have some competition for budget. Dan

X Roadmap?

Ah, there's probably a joke in there somewhere about crossroads and hidden treasure, but I can't find it...

There is no specific roadmap

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

Re:There is no specific roadmap

This is a work in progress.

I wasn't expecting it to get slashdotted.

Roadmaps show you where you were, where you are, and maybe where you are going.

I plan to do more on where things are going...

And it would be good if other projects did roadmaps of their own projects.

Jim Gettys....

I though he was working on all the termcap stuff...

One cool thing in the roadmap...

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.

Enough is Enough.

I don't mean to X-Bash- leave that for xterm and Konsole- but I, for one, am ready to welcome our YWindows overlords [slashdot.org], 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.

xouvert?

For anyone that doesn't know:
The Xouvert Project [xouvert.org]
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)

Re:xouvert?

maybe because xouvert doesn't have anything to show? Fri Sep 26 23:57:50 PDT 2003 marks the latest news on the website, although its roadmap indicates a "release" for November. I guess we'll just have to wait a little more and see.

Menus

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.

A new respect...

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.

Why is it still called X-Windows?

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.

Does anyone still use Metro-X?

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.

Bring it on

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.

VNC vs. X

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.

Re:Bring it on

Yes sir, yes madam, we have our first customer, roll up, roll up, see the troll feverishly attack the non-existent target.

As has been said many many times before, the network transparency does not affect the local transport. The X team amongst others have done tests (you know, where you measure things), and the implementation (using unix sockets, which are massively efficient data-transports, and shared-memory (no transport at all)) is as fast as you can get. It's within the theoretical margin of error of the peak performance of the system. Nothing goes faster.

I can't say this any simpler. X is massively efficient on the local channel. Direct-X on the PC is a different name for the same thing - an API into the low-level drivers.

You might argue that the low-level drivers are in need of optimisation, and I might agree in some cases, but that would still be the case for any new system. X itself is pretty bloody good at getting the maximum performance out of any hardware you throw at it - try running the 2-D blit in X11perf, then multiply the area * bitdepth * fps, divide by your AGP bandwidth and read the number you get .... You'll be surprised if you're running nvidia or ATI cards. Even venerable matrox cards push the bandwidth limit ...

Simon.

Re:Bring it on

Your attitude only shows your ignorance.

If an X users doesn't need network transparency, chances are very high that she doesn't use any code that is network transparency related -- this is the current default, after all.

In such situations, X applications communicate with the graphics subsystem over shared memory, just like in Windows. The difference is that the graphics subsystem is not part of the kernel but in user-space, and is called a server in tech jargon.

So, now that we have already what you want -- can you please step back and let the knowledgable people improve X at those places where it would really matter?

Re:Bring it on

Actually I disagree.

The unix credo is to build tools that work well within themselves and interoperate well with others.

"Be generous in what you accept, and rigourous in what you export".

The (completely transparent) use of ssh for network compression/encryption is not a quick hack, it's an example of two well-designed tools working well together. When one is optimised/improved/whatever, the other automatically gains the advantages. Why would you change ?

Besides, if you claim X should be trimmed down to "remove the network transparency", surely you wouldn't want to further lumber it with compression and encryption ?

And another point - I think X has plenty of deficiencies (just that compression/encryption aren't one of them), and I'm open to good debate on the subject. I was mainly referring to those who use any X-related topic to say "X sucks"...

Linux Desktop

X, Fluxbox, RXVT, Bash. What more do you need?

how about basic copy & paste?

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.

Re:how about basic copy & paste?

Umm, X's clipboard does work in a universal alt-c/alt-p type way (although some programs do have different bindings, e.g. ctrl-c/ctrl-p).
You are aware that the selection/middle-mouse buffer is not the clipboard at all, right? There is a completely seperate and proper clipboard, which is why most programs have Edit->Copy/Paste menu entries. People do tend to get confused and think the selection buffer is the same as the clipboard. IT IS NOT.

Re:how about basic copy & paste?

For a fuller explanation of how the selection buffer and clipboard work, see this [jwz.org]

Jim Gettys?!?!

BOSS Jim Gettys? As in, the corrupt politician with something less than a chance [americanrhetoric.com] of being elected Governor over Charles Foster Kane???

I thougt he was fictional!

Very interesting article

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.

1992?

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!

Two request about XF86..

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.

Didn't mention

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.

What about rotation?

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?

Funny, I don't see anything about...

... who's going to have the next hissy fit or fork off a new branch because their not allowed CVS access or any responsibilty due to the arrogance and narcissistic self importance or certain people involved in the project?

Did I miss something?

cLive ;-)

-1 Flaimbait :)

Good comparison of window managers

Just found this [gilesorr.com] comparison of "The Other Window Managers". It's an interesting read.

Or perhaps crappy implementations (X Color mgmt)

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.

Obsolete?

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...)

Didn't Xfree86 fork?

If I recall one of the members who wrote dri and some of the font servers quit in disgust and is writing his own X server from scratch.

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.

Adobe's SVG viewer doesn't work on X any more

How ironic the wording:

There are a few reasonably common datatypes for which there is no good native plugin available (fewer and fewer as the months go by).

Let's talk about SVG. Yes I know Mozilla supports a subset of SVG now (but not by default), however it's got a long way to go before it's anywhere near the abilities of Adobe's SVG viewer plug-in.

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

My favorite quote so far:

"Bad spec, Bad process, Bad engineering, Bad standardization process. What's not to hate?"

(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:

"Security

The Security extension was introduced to address the security issues of mixing trusted and untrusted clients on a single X server, according to compartmented mode workstation thinking of the early 1990's.

It is not clear at this date whether it serves any useful purpose in today's environments, though it may be useful in the case of shared display walls.

If you think its facilities are useful, please let your opinions be known, along with concrete examples of real circumstances where it is helpful."

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

Re:How sad.

What exactly are "the big issues"?

Re:How sad.

It seems the X developers *still* do not get it, there is nothing here that is going to address any of the big issues with XFree, just more of the same.

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.

Re:Stallman hates X-Windows

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.

Re:Stallman hates X-Windows

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.

Re:Correction

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.

Re:Stallman hates X-Windows

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.

Ancient News

Right... except for all this happened back in 1998.