Are there replacement(s) for the X windows system?

Su-Shee · 11-12-2007, 12:06 PM

Well, it all comes down to one thing: Someone's got to sit down for a certain amount of time and program an x replacement.

As I've been a project manager at the place, where parts of directfb have been developed and the decision of throwing away X and Gtk was faced and build a new GUI system from ground up instead, I can tell you: It's absolutely not that easy as everyone (silently) hopes and even if you've got the money to actually pay people to develop an X alternative full time, you still probably wouldn't have it within a year.

Not stable, not really fast, not secure, not with all the nice, cool and nifty feature one would like to get from a contemporary GUI - which also is a rather fast changing target, if one considers ideas beginning with Compiz up to Prism/Moonlight/AIR.

Not to mention if an X replacement would be really something utterly new, a technologically state-of-the-art whatever thingie - there's all the widget sets to port to something new and possibly all the applications using them to adjust.

However, AFAIK (some/many) Gtk-applications can run on top of directFB without any X in between.

V!NCENT · 11-12-2007, 01:55 PM

@Su-Shee:

It almost sounds impossible, huh? I guess it all depends on the design of the software. Bad design dissisions could lead to a major catastrophe and lots of extra work. But just, just just, pretend it is doable. What would be a good design? You obviously have a lot of experience

Su-Shee · 11-12-2007, 03:35 PM

No I don't, I just gained experience enough to not burn my fingers in something like "an X replacement".

And X works for me perfectly fine since 1993; I got all and everything up and running, I'm more and more satisfied how fonts and overall GUI stuff is developing under Linux - so, no complains from my side.

And as there's also a Perl module to write Xlib code, I even don't have to get my hands dirty with the real thing...

And I'm rather sure - the more I see and the more I read - that many GUI toolkits and most applications don't get the best out of the possibilities of X.

A nice introductionary book instead of the 6 (7?) issues of ORA - that would be my wish. I'd like to know more, but X isn't the easiest thing to get a grip on.

Blrfl · 11-12-2007, 04:12 PM

Quote:

Originally Posted by V!NCENT

X refers only to the protocol you say. Can you tell me what the specification and the implementation is called (X, X11, X?r?.?, X.Org/XFree86?)

As I said earlier, what makes X tick is the protocol. You can throw away and re-implement anything you like on the client or server ends and still have a functioning system. A number of other things (Xlib, Xt) are standardized, but they're really just gravy because a client based on something other than Xlib that speaks the protocol is still just as much a client. A good place to start is by reading the X(1) and XStandards(7x) manual pages.

The protocol specification is included in the source, which you can get from http://ftp.x.org/pub/X11R7.3/src. Look in the doc directory for a tarball called xorg-docs. The O'Reilly X Window System series of books used to have a Volume 0 called the X Protocol Reference Manual. It was much easier to digest, but it's been out of print for quite some time.

The current reference implementation is X.Org's, and it's simply called "X.Org." That implementation is what shows up in a lot of Linux distributions. XFree86 is still making releases, but a lot of their stuff eventually shows up in X.Org. I don't know what the relationship is there; maybe XF contributes new code after it's had a release or two to mature.

BTW, I misspoke before when I said all of the alternative server vendors for Unixy systems were out of business. Xi Graphics is still selling its product, and there are still a number of commercial products available for Windows like Hummingbird eXceed and Micrographics' MI/X.

Quote:

...the protocol has nothing to do with local hardware interaction code, or am I wrong? I have a question about that BTW: is hardware interaction different when I run GLX?

Your first statement is correct; the protocol is usually independent of the hardware. I say usually, because there's nothing stopping you from writing an extension (both sides, server and client) that allows clients to manipulate things specific to that hardware. However, it's usually the case that extensions (i.e., executing OpenGL primitives, displaying a video stream) are designed not to be hardware-specific.

Hardware interaction is contained entirely in the server. (On Unixy systems, it's a userland process like everything else, so there's some help from the OS.) You don't really "run" GLX per se; you run a server with the GLX extension in it and you run clients that may require it. The "usual" server-side code for the GLX extension executes the OpenGL primitives in software. If you had a graphics card with an OpenGL accelerator in hardware, there's no reason you couldn't plug in server-side code to take advantage of it as long as it doesn't break the protocol used by GLX. The client won't (and shouldn't) know the difference.

Quote:

That's all closed source. How can that compete on a open source bias?

Didn't know that was on the table as a requirement. You have to put yourself into the context of 1985, when open source was still in its infancy and the list of large open source projects was very, very short. The fact that it was open source helped X gain as much traction as quickly as it did.

Quote:

Then why are you so against a replacement for it? How would you design it if you were to create a new X that isn't X?

I'm not against replacing X, I'm against prematurely replacing it with something else that might not be ready for prime time. I was a very happy SunView user and had developed a few small applications for it before X became stable enough for me to use on a daily basis. X went through growing pains in its early years, and whatever is in line to replace it will as well. Window systems weren't exactly novelties 20 years ago, but many of us did most of our work on dumb terminals, and the graphical environment gave us a multiple-dumb-terminal environment with some extra niceties. I can (and do) still work on a terminal when I have to, but it's so much nicer with the graphical environment that's evolved with me over 20 years as my base of operations. I could find my way through a new paradigm, but I can't say I'd enjoy it, especially when I have other work to do.

I haven't given much thought to what I'd do if someone said they'd pay my current salary to spend my days coming up with the next non-X X. Honestly, I don't know if I'd take them up on it. My time to frolic in the bowels of windowing systems was the late 1980s and I've done my bit of innovation in that field. The current, slowly-evolving X11 does what I need. When it doesn't, I'll switch.

What will replace X? I can't say, because it's been more than a decade since I last kept up with the field. If I had to bet, I'd put my money on it being something based on a rendering language like SVG. That would be a case of what's old being new again, because NeXT and Sun did that with Display PostScript in the late 1980s. The hardware just wasn't fast enough then, but it is now.

--Mark

V!NCENT · 11-12-2007, 04:34 PM

@Mark (Blrfl):

Very informing post

Ok so maybe it's better to stick with X instead of duplicating what it can allready do. If I want to design a GUI system that works the way I would like to see it I'd better focus on the future and create something entirely new altogether. Have you, or anyone else, got ideas/dreams about futuristic graphical interfaces? Maybe something that hasn't got windows but speech interaction or maybe modulair interface objects like drag-and-drop a search engine from FireFox into OOo to search documents or something?

Tinkster · 11-12-2007, 06:04 PM

Quote:

Originally Posted by Blrfl

As I said earlier, what makes X tick is the protocol. You can throw away and re-implement anything you like on the client or server ends and still have a functioning system. A number of other things (Xlib, Xt) are standardized, but they're really just gravy because a client based on something other than Xlib that speaks the protocol is still just as much a client. A good place to start is by reading the X(1) and XStandards(7x) manual pages.

The protocol specification is included in the source, which you can get from http://ftp.x.org/pub/X11R7.3/src. Look in the doc directory for a tarball called xorg-docs. The O'Reilly X Window System series of books used to have a Volume 0 called the X Protocol Reference Manual. It was much easier to digest, but it's been out of print for quite some time.

The current reference implementation is X.Org's, and it's simply called "X.Org." That implementation is what shows up in a lot of Linux distributions. XFree86 is still making releases, but a lot of their stuff eventually shows up in X.Org. I don't know what the relationship is there; maybe XF contributes new code after it's had a release or two to mature.

BTW, I misspoke before when I said all of the alternative server vendors for Unixy systems were out of business. Xi Graphics is still selling its product, and there are still a number of commercial products available for Windows like Hummingbird eXceed and Micrographics' MI/X.

Your first statement is correct; the protocol is usually independent of the hardware. I say usually, because there's nothing stopping you from writing an extension (both sides, server and client) that allows clients to manipulate things specific to that hardware. However, it's usually the case that extensions (i.e., executing OpenGL primitives, displaying a video stream) are designed not to be hardware-specific.

Hardware interaction is contained entirely in the server. (On Unixy systems, it's a userland process like everything else, so there's some help from the OS.) You don't really "run" GLX per se; you run a server with the GLX extension in it and you run clients that may require it. The "usual" server-side code for the GLX extension executes the OpenGL primitives in software. If you had a graphics card with an OpenGL accelerator in hardware, there's no reason you couldn't plug in server-side code to take advantage of it as long as it doesn't break the protocol used by GLX. The client won't (and shouldn't) know the difference.

Didn't know that was on the table as a requirement. You have to put yourself into the context of 1985, when open source was still in its infancy and the list of large open source projects was very, very short. The fact that it was open source helped X gain as much traction as quickly as it did.

I'm not against replacing X, I'm against prematurely replacing it with something else that might not be ready for prime time. I was a very happy SunView user and had developed a few small applications for it before X became stable enough for me to use on a daily basis. X went through growing pains in its early years, and whatever is in line to replace it will as well. Window systems weren't exactly novelties 20 years ago, but many of us did most of our work on dumb terminals, and the graphical environment gave us a multiple-dumb-terminal environment with some extra niceties. I can (and do) still work on a terminal when I have to, but it's so much nicer with the graphical environment that's evolved with me over 20 years as my base of operations. I could find my way through a new paradigm, but I can't say I'd enjoy it, especially when I have other work to do.

I haven't given much thought to what I'd do if someone said they'd pay my current salary to spend my days coming up with the next non-X X. Honestly, I don't know if I'd take them up on it. My time to frolic in the bowels of windowing systems was the late 1980s and I've done my bit of innovation in that field. The current, slowly-evolving X11 does what I need. When it doesn't, I'll switch.

What will replace X? I can't say, because it's been more than a decade since I last kept up with the field. If I had to bet, I'd put my money on it being something based on a rendering language like SVG. That would be a case of what's old being new again, because NeXT and Sun did that with Display PostScript in the late 1980s. The hardware just wasn't fast enough then, but it is now.

--Mark

Just a quick thank you for signing up and the contributions.

That was amazing in both the quality of content of your posts
and the manner in which you're handling those posts of an
almost "trollish quality" :}

Cheers,
Tink

V!NCENT · 11-13-2007, 03:30 AM

Quote:

Originally Posted by Tinkster

That was amazing in both the quality of content of your posts
and the manner in which you're handling those posts of an
almost "trollish quality" :}

Yes I'm sorry but my intention was to critisize it. I jumped of the 'X is bad' bandwagon. I quess my posts weren't mature and I apologize for that.

Blrfl · 11-13-2007, 07:02 AM

Quote:

Originally Posted by V!NCENT

Ok so maybe it's better to stick with X instead of duplicating what it can allready do.

I think you'll find that if you take a long, hard look at X, it really doesn't do much of anything. That may not sound like high praise for a window system, but that's exactly what's given X its staying power. Scheifler and Gettys aptly described X as a substrate for building graphical environments. The fact is that everything a lot of people people refer to X-- like KDE, GNOME, various widget sets, etc. --are all just clients directing the server to make windows and draw things in them. If you start an X server and no clients connect to it, all you'll see is this (chopped down to 800x600, but you'll get the point).

Even the window manager is just another client that takes liberties with other windows. I've used a lot of them in 20 years: UWM, TWM, OLWM, MWM, VTWM, FVWM, Sawfish, IceWM, Enlightenment, Metacity and probably a dozen others that I've tried out for a few hours just to see what they were like. Despite a very wide range of appearances and feature sets, the X underneath all of them has remained almost identical.

That's another nice thing about X: you can mix environments freely in the same session. I'm running Metacity and GNOME right now, and if I want to fire up Konqueror (KDE), GIMP (GTK) or xfontsel (Athena), I can, and they'll work.

--Mark