Slashdot Mirror
picoGUI: An X Alternative?
bockman writes "While started as a PDA-oriented project, the picoGUI people seem to be implementing many ideas which I think would be good also for a desktop graphics server ( high-level client/server protocol, presentation layer in the server _but_ modular, application management also modular,...). So I wonder: what would it take (apart porting tons of applications) to make it a suitable alternative to X+[your toolkit of choice]+[your window manager of choice]?"
So I wonder: what would it take (apart porting tons of applications) to make it a suitable alternative to X+[your toolkit of choice]+[your window manager of choice]?
It would take a reason to replace X. Sure, there's plenty of papers on how X is atrocious and should be scrapped, but it's a protocol that works well. It's been in use for many years and most implementations are pretty fast. In all my years, I still haven't come across a reason to move away from it. If an alternative comes along that offers something X doesn't, then I'd consider it, but it doesn't look like that will be anytime soon. X meets all my needs.
Is your browser retarded?
Before one embarks on such a nobel product, he or she must be prepared for X conquest. Otherwise, he or she will end up like the dozens of alternative-to-X windowing systems littered strung out across the Internet. Don't be a another casuality of X-crazy fanatics; X can be replaced, but only by time.
"The lesson to be learned is not to take the comments on slashdot too literally." --Vinnie Falco, BearShare
The entrenched X API is the biggest roadblock to projects like these. It's almost easier to put picoGUI into a new OS rather than trying to make it replace X in Linux/BSD/UNIX.
But if the X API can be put on picoGUI, then it's something to think about. Otherwise I'll stick with XFree86, which is getting faster and smaller with each release.
A Government Is a Body of People, Usually Notably Ungoverned
I'd love to hear exactly what it is you "hate" about X, and where you think its "pitfalls" lie.
The one thing I'd like to see is a set standard GUI services on top of the core drawing engine. Different widget toolkits would be a thin wrapper on top of these standard services, and different widget toolkits would exist to customize the standard services to each language and development model. This way developers could code to whatever API they enjoy (Qt'ish, GTK+'ish, etc) but since these APIs would map to a common set of services, applications would interoperate perfectly. In fact, with would then be easier to write wrappers for "legacy" apps that use straight GTK+ or Qt.
A deep unwavering belief is a sure sign you're missing something...
It is so sad that many in the linux community are so obsessed with "eye candy" and the latest experimental GUI. The flexiblility of LINUX when it comes to the GUI gives it enough rope to shoot itself in the head with. I know the reason why most of my friends work with MS windows and the Mac OS... there is a uniform user interface that works (flaws and all) fairly well. I don't have to sit there and think... gee do I have widget set X with static libraries Y and did I make the right offerings to the gods of LINUX... you get the picture. So picoGUI looks cool... who gives a sh.... (of course this will be modded as flaimbait... since I don't slobber at every would be GUI posted on slashdot)
That's just a theme, you idiot. I'd like to see you do better.
If you provide the X-windows service, then you are an X-server, whether you call yourself one or not. So I'm not sure what it would mean to emulate X. If you somehow support X plus some other features, then that would be more like extending X than emulating it.
Personally I don't have any problem with X. I like it. Most of the sensible complaints I hear about it seem to be coming from people who want features that aren't there yet, or who feel the performance isn't up to snuff. These are almost drowned out by people who don't really seem to understand what X does.
I mean, X is a fairly generic display system, as witnessed by the fact that blackbox, matchbox, twm, fvwm, enlightenment, etc, which all look very different, are all just X clients.
Anyway, it might be possible to address the features issue and still have emulation, but I don't think that performance issues will be solved by emulation. And, when you look at all the graphical programs that use X, it seems kind of hopeless to expect that X will go away and be replaced by something else.
Although, if you could port, say, motif and gtk to some new, non-X system, then you could probably leverage a lot of other stuff over to that system relatively quickly.
MM
--
By including this sig, the copyright holders of this work or collection unreservedly place it in the public domain.
X is a well-designed system which serves everyone's needs, works now, and is compatible across the UNIX world. It would take a lot to displace it.
More to the point, in discussions like this everyone always says... "of course it would have to be backward compatible with X..." But these people fail to understand that the only way to be backward compatible with X is to implement the X protocol stream. And once you do that, ta-da you're an X server once again, just like XFree86.
Of course, if your lovely new GUI doesn't reimplement the X protocol and the client/server model, you render useless decades of program code, from ancient embedded applications all the way to current UNIX ports of OpenOffice and Mozilla, from astronomical observatories to cash registers.
And of course, then you will lose one of the biggest benefits of X: the X protocol stream and the client/server model. D'oh!
X is not going away.
STOP . AMERICA . NOW
Basically, everything depends on X, so you can't really replace X and maintain backwards compatibility. In order to have backwards compatibility, you would need to provide all the services provided by X, so you would, in effect, just be writing a new X server.
If you really want to replace X with some other system, then you could probably get pretty far by just porting gtk and motif over to the new system. This should pick up quite a few apps. I have no idea how hard this would be.
But, by and large, it's silly to constantly rant and rave about X. It's just an abstraction for a video driver that allows you to effortlessly traverse networks. It is so low level, that it almost doesn't make sense to criticize it. And I think many of the critics don't really understand fully what X is.
For example, if you don't like the performance, then that is a complaint against the specific Xserver you are running, not against X itself.
If you don't like the widgets you are using, then that is a complaint against the widget set you are using (motif, gtk, qt, etc.). This has nothing to do with X.
As far as features go, if you really want a feature and X does not provide it, then you have a legitimate complaint. But really, what more do you want from a video (and mouse and keyboard) driver than the ability to get information about GUI events and to paint the screen in any fashion you desire?
To sum up, I don't see that X is inherently problematic. I think that most complaints about it are misplaced, and should be directed elsewhere.
Furthermore, when people talk about replacing X, they seldom seem to appreciate the benefits of allowing the application to connect to the server over the network. This is one of X's strongest points, yet most people seem to want to replace it with what ammounts to a widget set rolled up with a local machine only video driver.
Well, that's my $0.02.
MM
--
By including this sig, the copyright holders of this work or collection unreservedly place it in the public domain.
Gtk+, Qt, Motif, Fltk+, and Tk applications are nearly indistiguishable visually and behaviorally. And the situation is the same on other major desktops as well: your average Windows and Macintosh desktop probably has applications written in half a dozen different toolkits.
If pico is reasonably modular and well designed, you could have different versions (different in complexity, hardware abstraction, your own ultimate widget collection, etc) and still use *every* app *native* with the different flavours of picoGUI
That's the wrong kind of generality as far as I'm concerned. I like programming to different widget sets because the APIs of different widget sets are good for different things. What you suggest is just what I don't want: a single, uniform API with different appearances.
You, and many other people, are muddying the waters by confusing Xfree86, a specific implementation of an X server, with the underlying concept of an X server in general. It is impossible for X to be a "big dumb slow ram hog" because it is really a description of a protocol for a display server.
It's a bit like saying that ftp is a big slow ram hog.
Furthermore when you say that X has no consistent look and feel, you reveal your complete lack of understanding concerning X. As I said, X is a display server. It can't really detract from a consistent look and feel.
What you might mean is that you wish the linux community could standardize on a widget set to make apps have a more homogenous appearance, or something like that. This is a totally reasonable goal, and I'm not arguing against it. I'm just pointing out that it has nothing to do with X in general.
Configuration is also an Xfree86 specific complaint. I used to use an Xserver on windows that was quite easy to configure. In fact, I think that all I did was install it and it worked. Later I used another, much fancier one, and found it even harder to configure than Xfree86.
Anyway, PicoGUI is about as close to displacing Xwindows as Jolt cola is to displacing Coke as the pre-eminent Cola drink.
MM
--
By including this sig, the copyright holders of this work or collection unreservedly place it in the public domain.
Say what you will about Windows but at least it's a standard to work against. With Linux it seems there always some pertpetual tinkering...enough already! Enough tool building, now make some apps.
Look how many freeware and shareware files are available for Windows. Sure, they're not open source but a lot of people are still writing apps for Windows. For example, go to hotfiles.com and search for "word processor". Quite a few choices. For Linux, you've got...AbiWord, Maxwell, WordPerfect, StarOffice/OpenOffice.
The point of all this is that most people don't care what's the newest/greatest/most different way of doing something. They just want something that turns on and works. So don't think about replacing X, think about making more applications for the end user.
And why do you need a freakin server for every tiny piece of bullshit?
Modularity. One of the nicest things about a true multitasking *NIX environment. If something doesn't work the way you want it to, you can take a piece of it, the piece you don't like, change it, and contribute it. Or install someone else's contribution. I'm actually glad there are a million complete little programs running around on this machine doing things that could be handled by one piece of software with everything integrated. Do you want about ten different sound servers, or do you want about ten slightly different versions of X to choose from? Make that twenty if there are even two different font servers. That would be the clusterfuck. I'll venture to guess that the modular nature of Linux is one of the major reasons people like it. Screw the idea of everyone agreeing on how it should be, even if that were possible. I love my Frankenstein GUI, and if I decide one day that I don't I'll log out and pick another one. Stupid Linux geeks don't have to work with whatever Microsoft or Apple (Or GNOME, or KDE) thinks their desktops should behave like. It's not for everybody; if you conform to Microsoft's market research, or Apple's, or that of the BeOS or Amiga folks, then their desktop is made for you. Mine is made for me, but only because I could customize the unholy hell out of it, and if I wanted something to be different then somebody, somewhere had written the code for me to change it. Yeah, keep a freakin' server for every tiny piece of bullshit, and God forbid it should ever be any other way.
Blame the clunkiness of the linux desktop on the linux desktop, not on X (in general) or Xfree86 in particular.
There are a lot of concepts associated with X on linux. X, in the form of Xfree86, is at the bottom. Then on top of that there is a widget toolkit (i.e., gtk+ or athena or motif).
Interacting with X is the window manager, which may use a widget toolkit, and which excercises control over placement, size and other characteristics of application windows. Each of these application windows gets to decide how the pixels it has control over should look, within the limitations of the display device. And, in many cases, these applications are built on top of a widget toolkit which may or may not be the same as the one used for the window manager. Then there is the "desktop" which is really just another application.
So, you see, "X" is probably not the cause of the clunkiness you perceive.
On the other hand, if Xfree86 is genuinely too slow, then you should build (or clamor for the building of) a faster x-server.
But don't throw out the whole concept of the x-server, for it gives us many benefits, perhaps most importantly, network transparency.
And, by the way, most people are not saying "Why change? X is ubiquitous!" They are either saying, "it will never happen: X is ubiquitous" or they are saying "Don't change it, because there isn't a superior alternative yet."
I, on the other hand, am saying "don't blame X for problems which lie elsewhere." And, perhaps, "don't put forth an opinion on X if you don't really know what it is."
Oh, and, "the PicoAPI has something like 70 functions in it. Let's not get carried away!"
MM
--
By including this sig, the copyright holders of this work or collection unreservedly place it in the public domain.
The basic concept of X is sound, mature and very farsighted. We have some implementation work to do, but we also need to remember to keep that seperate from the actual value that X provides.
:)
Most people here like UNIX right? You can package all of those X complaints up and apply them to UNIX in general. When you do, Guess what? They are the same arguments. All of the things that make UNIX like systems, such as Linux, a good thing are the same things that drive some people nuts about X.
The reality is that using a *real* computing platform requires a little learning. In the last 4 years, the rate of improvement is astounding really. One or two more years and it is going to be solid.
X is a part of that work and brings with it some serious benefit. Again, I ask: "Why trash all of that, just so we can start all over again with a simpler and more limited system?"
It is not worth it.
There is a trade off between easy to use, and capable. You can also factor in common knowledge to understand how this applies to X today. Lets call this the "happy point".
Right now, there are a lot of people who got started not knowing what network transparent display systems actually mean. This is because the platforms they worked on did not have them.
So common knowledge is low for people coming to Linux right now. So the "happy point" is way toward the ease of use side of things. Makes sense really, because you don't miss what you don't yet understand.
Over the next couple of years a few things are going to happen that will essentially make this point moot.
X configurators will get done for most people. Most of the hard stuff will be abstracted into a few sensible combinations that people need and they will work. Progress so far shows me this will happen.
Some of the brighter ones will start understanding just what X is giving them and will start liking it. Articles, reviews and product feature checklists will start to mention this point.
Remember X is a serious differentator for UNIX like systems. It allows us to do things that make a lot of sense and provide a lot of value.
X server performance will cease to be an issue. There is simply nothing that prevents X from being as fast or faster than the very best frame buffer systems. Nothing. I have old SGI machines with simply *excellent* X servers. They understood X and made it work to its best advantage. The result: 30 Mhz machines that are just as snappy as the machines of today.
Don't tell me X is inherently slow. For each argument, I can point to the source of the problem and that source will be implementation, not the basic premise of X.
So all of this will help to raise common knowledge. As this goes up, that "happy point" will move over toward the capability side of things.
After a couple of iterations, we will wonder why it was such a hassle. I did when learning and it was harder then. Now it is fairly easy. In a couple of years, the things people want most will be in the GUI, for the rest of us, we can continue to meld X into performing whatever display task we want.
Only well planned scalable software with vision does this sort of thing. UNIX does it, thats why we like it, X does it, and that is why we will like it too.
I am *really* tired of hearing X sucks tirades. Is this bash X weekend or what?
Guess I will have to just post X is good tirades each time. Perhaps the truth lies between
Blogging because I can...
As many other people have pointed out, X is fine. Problems people have with "X" are really problems with either the implementation of X, or problems with their widget set. People complain X is slow. Now, X isn't slow: you're using a crappy implementation, or crappy drivers. Its not X's fault. Get better drivers, get a better or update implementation. Go to XFree86.org or try out Accelerated X. If you want a certain feature that's not there, its probably your widget set.
In short, before you say X sucks, identify your problems with it, and ask some experts about how to resolve them.
One thing that I will criticize X for, however, is that they don't enforce some kind of standard for interfaces. One thing Linux does need is standardized interfaces and key combinations between applications. There doesn't need to be one standard, but apps installed on a user's computer should all obey the user-defined standards. CTRL-V should always past...it shouldn't be CTRL-V or ALT-V or CTRL-P depending on the app. Same thing with menu's and stuff. Why should every developer have to reinvent the wheel? And why should the user have to reorient himself for basic key combinations for every program?
social sciences can never use experience to verify their statemen
I have to agree, do a "ps aux" and take a gander of whats running when you run gnome.
I'd like to take this opportunity to plug windowmaker here;-)
I'm not trying to put down gnome here, some people love it, hey if it works for you cool.
This is what makes x cool, you run gnome I run wmaker and we can do it on the same machine running the same apps, at the same time if we get trickey and have the horse power.
X runs pretty damn fast on my dual celery 500
You got complaints with XFree development, then "throw your stone into the soup," with your own ineffable coding skills -- or hold your criticism. To work a weary truism, you look a gift horse in the mouth!
The XFree86 effort is about 10 years old. Twenty years ago (I was there) we had dedicated, proprietary VECTOR graphics terminals, one per PDP-11, please! Raster graphics were a dream, waiting for advances in (gasp!) bubble-memory... Never happened that way.
The XFree VOLUNTEERS took the X11r5-6 standard and reproduced it for free commodity systems. In six or seven years, they equaled proprietary vendor efforts, without the benefit of proprietary access to hardware! In the past three years, these developers have been working to advance X11 beyond any earlier realization.
X is a good design, and extensible enough to be with us still today. Sure, I would have been ecstatic if NeWS had prevailed politically in the 80's Unix wars, or that NeXT's DP had grown up - but the DEC committee won out for openness, and number of players invited to the table. The downside of comittee design: Xlib sucked, and every toolkit ontop of Xlib perprtrated the crimes. It's still just a library - better ones are here and arriving - if nonstandard. Even JZW's famous excoriation of X11 is based on Xlib and Motif toolkits, not X11 architecture or design features. These are not dismissable any easier than is Unix.
Paraphrasing the truism, I would advance that "Those ignorant of X11 are doomed to re-invent it -- badly."
"Flyin' in just a sweet place,
Never been known to fail..."
We have three computers in our house on three levels (Duron, K6, Laptop). With X, I can log in to any of the computers from any of the other ones and start working just as if I was sitting right in front of it (my wife, who was a Microsoft consumer only before she met me, had a Dickens of a time understanding that concept). I need network transparency.
I also use two desktops, depending on the load my applications are going to put on the machine and if I feel like eye candy (KDE and Blackbox). With Blackbox (for non-Unix people: lightweight, minimal window manager), I can do amazing stuff on my K6 because the GUI is not sucking up all the resources (aka "Morbus microsoft", now also known as "Morbis apple"). I need multiple window managers because of different resource needs.
Now I'm sure you could probably include these in picoGUI, but then all you have done is made a new version of X without the decades of testing that has gone into the real X. Come back when your software has a track record of more than ten years, and I might look at it for a core system: I want proven stability. The last time my X crashed it was because of Nvidia's shitty closed source drivers; since I switched to ATI, it is solid like a rock.
Oh, and what about those old graphics cards I have sitting around here? Are you going to backport every single driver, so I can still use my Oak VGA card with 512 KByte RAM? That might not sound like much, but with X Window and that card and a PI or even a 486, I can still build an X terminal and hook it up to anything. I want maximum hardware support.
No thanks. Enjoy yourselves writing picoGUI, it's a free Internet and and new software is always a good thing, but don't expect to replace X. If it works, don't fix it.
Since all of these are very much different from X. Some of the projects mentioned go way beyond anything proprietary GUIs can do today! So if we are reinventing wheels, at least we are improving allong the way.
Regards, Tobias
Regards, Tobias
I think it would take something amazing to replace the X Window System. There have been a few attempts to replace it. picoGUI appears to be a inspired by QNX's Photon microGUI (hence the blatantly similar name).
I think you hit on the real problem though, standardization. There is no single central Unix vendor than can dictate UI design standards or enforce a single widget toolkit. picoGUI has a snowball's chance in hell of becoming the defacto widget/windowing system. Hence it will just serve to fracture the UI experience even more.
My complaint about the UI on Linux/Unix has always been that it's so frickin inconsistent. Too often apps do things differently. Not better, just differently. Everyone can make their own super neato widget library and it's not that hard to make your own X replacement.
That's the problem. Don't try to invent your own window system, menu ordering or UI interactions, just base them on Windows as much as possible and forget about "the best" way to do things. With KDE (don't know about Gnome, never liked it) that is happening, slowly. Maybe picoGUI is taking the right approach by limiting the ability to make apps with fucked up GUIs just because you can and "Windows sucks", but most Unix diehards will loathe the loss of flexibility.
-Kevin
Instead, fix the current one.
Current wheel ( X ) comes in several colors ( platforms ), the protocol is universal ( remote display too ). X is mature, and has millions of programs written for it NOW.. not SOMEDAY..
It has all the functional components that is needed in a graphic subsystem.
Sure, its *not* perfect, but spend the time enhancing it instead of tossing it out.
Plus people need to learn to sepreate the X subsystem to the GUI on top before they start comparing things... One cant accurately compare wheels to bricks..
---- Booth was a patriot ----
To come to your point, no, picoGUI cannont embed the X protocol (it would be against its basic approach). But il could be possible (though not easy) to make 'compatible library' that traslates GTK+ API (or QT API) into the picoGUI
Another solution, perhaps better, is to make an X toolkit that uses the picoGUI API. Then an application won't care if the system has picoGUI, or is administered by an old fart with X.
A Government Is a Body of People, Usually Notably Ungoverned
The reason X is mistaken for GTK is because most normal average computer users don't know the difference. One sees GTK based programmes and window managers such as the GIMP and GNOME and assumes that that IS Linux. Those that use SuSE see KDE and wonder why ALL programmes don't use that (including the GIMP, notwithstanding the fact that GTK comes from the GIMP). The point is that average users don't know or care why the GTK toolkit is so incedibly ugly (for them looks DO matter) or why X is not very flexible or easy to configure. They just give up and either use KDE or go back to Windows or use Mac OSX.
Linux needs one standard windowing protocol and system, either GNOME or KDE, not both. The continual clashing is hurting Linux and making it harder for developers. Time for a change.
But to answer the question:
1. Any "captive" application - think stripped browser on a kiosk - could use Pico.
2. If the TOOLKITS which are (or should be) platform-neutral are ported. Qt is probably a good candidate. The Zaurus already runs QPE and Pico separately, but it isn't much of a leap to do QPE (already over Qt) over PicoGUI.
But before you get too excited, the code is still in an early state, at least as far as compiling on every platform. It keeps client-server though.
And I need to address some other comments about X.
First, it isn't that slow, and one of the problems is that a lot of software is assuming SHM or other extensions that force things to be local.
Second, dxcp or other programs can compress the X stream to make it usable over some slower links and would reduce bandwidth in any case.
Third, if you are doing remote control or something similar, VNC or something similar is the correct solution.
Fourth, X is the basic set of protocols. But in many references they mean X plus every toolkit, extension, and window manager and probably a few applications. Some things are only big because of these accretions.
Citrix, or almost anything else on Windows is a hack since Windows was never designed to work remotely.
You can criticize X all you want, but it is opensource, so you can fix or enhance the problems, and it seems to work well enough to allow the wide adoption.
And PicoGUI addresses one of the major points - the need for a lighter weight system for embedded and small computer use.
It's just a huge step backward. You give up network transparency and make lots of applications incompatible without gaining a thing! You might gain a tiny speedup, probably not even that. Most time is spend in the toolkit anyway, you are obviously not cutting out that part.
Of course PicoGUI, Fresco and others suffer from lacking applications. They are for most part in alpha stage! But with a bit of work you can
So you keep the revolution and the applications;-)
Did you ever bother to read up on the projects mentioned in this thread? We are not talking about some X-without-networking here (like what you were calling a evolution)!
Regards, Tobias
Regards, Tobias
I don't know how many of you have actually used the Photon microGUI on QNX, but I believe its the way a GUI/windowing system should be designed.
Its simple, its clean, its fast, and it provides a nice network extensibility (using QNet).
Could X be all of that. Yes. But not in its current state. To me, X seems much bigger than it actually needs to be.
X really isn't as bad as many make it out to be. X is -NOT- slow -- it's just that KDE and Gnome are bloated. Not only that, but while I don't intend to troll, the interfaces aren't very consistent, even with themselves.
As Guillaume Maillard stated on OSNews, X can be made to be fast.
The man reason I don't like X is because of GUI inconsistencies. Even when Redhat used the same theme on KDE and Gnome, I would still see a lot of inconsistency in applications. I don't have a current Redhat install right now, but if I remember correctly, launching KWrite from Gnome would have "bad-feeling" scrollbars. In short, it's not just the look of the widgets that matter, it's also how they behave. CONSISTENCY IS IPMORTANT as far as I am concerned. (Ironically, I prefer using WindowMaker over KDE and Gnome. The desktop's interface feels faster as a whole, but applications are still as inconsistent as ever.)
So really, the problem is not as much speed as it is consistency. If PicoGUI manages to emulate X, what good will that do us if interfaces are still clunky?
There's nothing wrong with X. Most of the problems that people have with X don't have anything to do with the stability of X, they have to do with the API/toolkit, environment (KDE or GNOME), and/or the window manager. Those are the entities that "crash" the GUI. The problem is that a lot of newbies and even moderate users are not familiar enough with the system to understand this. They assume that because X disappeared off their screen, that X is to blame. I used to think this way as well, but after having gotten into Linux really in depth and compiled X a few times, I see now that the real culprit are the X clients, not the X server itself. The only thing the X server does that would lead someone to this conclusion is that it usually restarts: (Screen goes black, and X restarts, either resulting in just the X cursor on the checked background, or a DM pops up 'XDM, KDM, GDM, etc...' And, last not not least, if you are starting X with 'startx' (unmanaged), then yes... the GUI just disappears and takes you back to a *sh shell.) The latest realease of X actually has a lot of really great features that a lot of users are unaware of. Features that put it on par, if not slightly beyond the Windows GUI. (Mac OSX still has X beat :( ) Of course, the best feature hands down is the network transparency. Running X apps remotely and having them display on a local system is just great and much more flexible than Windows XP RDP. Especially since you can have applications running on several different systems all displaying on the same desktop (not in separate windows like RDP). Combine this with the Low Bandwidth Extensions (lbx) and you can do this over slow links with speeds that are pretty close to RDP. Your local X display becomes the main head for multiple servers this way! How cool is that?
Of course, there is plenty of antialiasing and subpixel shading (for laptops) that again is on par with Windows XP's GUI.
Overall, X is actually extremely stable, but ti does need a few improvements. I think the biggest flaw in X that makes people think it's unstable is that the session needs to restart when an app or client session dies. If X could be kept active and just allow the clients or apps to reconnect without ever going away, I think you would see a lot of people change their tune about X. It would also be nice if X allowed for reconnection of stateful sessions (Like XP allows for multiple users to be logged in with apps running). I'm not sure, but I think Xnest might allow for this, although I haven't tried it.
The biggest problem with X is that a lot of the extra functionality is not easy to use. lbxproxy (for low bandwidth connections) could use a nice GUI based tool combines with ssh to make setup really simple. For example:
1. You run the LBX Proxy Connector GUI on your local system. You enter the IP address of the remote system, select whether you want to run a specific app or a complete session (GNOME, KDE, etc...) and then click the connect button.
2. In the background the Proxy connector establishes an ssh connection to the remote system and executes the appropriate ssh commands to run the remote app or environment with lbx, and establish an ssh tunnel.
3. Locally, you see the app appear on your current desktop, or a new X display starts and runs the remote environment.
That would just be damn cool. You would get compression, encryption and either just the remote apps you need, or an entire remote session (KDE or GNOME).
So... please don't say that we need to get rid of X. Having alternatives to it that are useful in certain situations but X is a cutting edge and very stable/mature system that only needs a few utilities added to make it easier to exploit all of it's functionality.
Un-news
OK, I'll come out of the woodwork like every other worm that's lived, loved and hated X for years.
I think X was ahead of its time with the network view of a server accepting requests.
In hindsight, no fault of the original developers, the problem is now that it was implemented before the advent of newer standards in network communications such as http and XML. Yes, the existing infrastructure works like a draft horse. But it would have a better future if it didn't do things its own way but relied on other standards, even if those standards were later in coming.
And, honestly, X didn't flow smoothly into vector based (PostScript) and 3D systems (OpenGL) except as "extensions" that are obviously afterthoughts. Sun's NeWS didn't win. And OpenGL applications under XGL behave differently than pure X applications.
It would be nice if a new frame buffer device manager would be written that incorporates some of those ideas and yet retains the network awareness of X, which I think is one of its strengths.
A well-designed successor to X should be layerable either below X or above X during a transition.
"Provided by the management for your protection."