picoGUI: An X Alternative? 564
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]?"
For the SI prefix challenged (Score:4, Funny)
Re:For the SI prefix challenged (Score:3, Funny)
The entire source probably looks something like the following:
I didn't realize DNA computing had arrived so quickly. God bless those researchers!
Re:For the SI prefix challenged (Score:5, Informative)
Re:For the SI prefix challenged (Score:3, Funny)
and if 25 cents is 2-bits then a byte is worth a dollar!
Re:For the SI prefix challenged (Score:3, Informative)
A good alternative! (Score:2, Interesting)
If this project can get it right, and avoid a lot of the pitfalls X has, and could run all the apps I needed to (flexible, back-ported API is a MUST to avoid tail-chasing), I would use it.
I'm interested to hear if anyone with significant experience using it could comment to its usability and compatibility?
Re:A good alternative! (Score:5, Insightful)
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.
Re:A good alternative! (Score:2)
No matter what OS you want to develop for, you need good development tools, and knowledge about the OS. Linux/BSD are perfect for this. I dont blame Xfree for the problems in X, driver support is what makes it suck.
Re:A good alternative! (Score:4, Interesting)
There is an X-compatibility module (Score:4, Informative)
Check out the screen shots [picogui.org] for more.
Re:A good alternative! (Score:5, Interesting)
To explain:
- with X protocol, in order to draw, say, a pushbutton, the client says to the server things like : make a rectangle filled with color X, draw a line, etc... (the application programmers don't see this because this is what the GUI toolkits are for)
- with picoGUI, the client only says: draw a button. It's the server that take cares of details, according to the currently loaded theme.
This brings a couple of advantages: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 API/protocol.
Re:A good alternative! (Score:5, Insightful)
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."
Re:A good alternative! (Score:2, Insightful)
Re:A good alternative! (Score:2)
That's just a detail... (Score:2)
Have you tried using dga modes?
There are some other problems, however, that won't go away ever...
Re:A good alternative! (Score:2)
Re:A good alternative! (Score:2, Informative)
Check out the slashdot story: RandR Extension [slashdot.org]
Re:A good alternative! (Score:3, Interesting)
No. Ok, maybe the monitor changes resolutions. Your desktop and all applications aren't aware of any change (like they would be in MS Windows for instance). Once you press Alt+/- in Xfree86 your entire UI experient is degraded by the constant need to shove around the viewport with the mouse cursor.
That feature is worthless for anything but a quick zoom-in on an image, or for testing refresh-rate configurations.
To answer your question (Score:5, Insightful)
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.
Re:To answer your question (Score:5, Interesting)
I don't understand. You mentioned plenty of papers of how X is atrocious and that it should be scrapped. Perhaps you haven't come away with a reason, but doesn't the fact that said papers exist mean that there are plenty of people who have one?
And doesn't that mean that perhaps an alternative should be considered?
My reason is that net connections require too much bandwidth. We use Citrix at school and get connection rates from Windows servers with than 2kbps needed. And it appears as though there is no latency in the connection, even though there is - i.e. it seems as though its running on my machine. Another big reason is that X requires so much from the clients. They have to be SERVERS themselves.
Also, the way it stands, if I want to share my X apps with my Windows friends, I have to get them to either
1) Pay a lot for a decent X server for Windows (by decent, I mean that it doesn't put all X connections inside one Window with a fixed size, but rather creates Windows each time a call is made - unlike Cywgin xfree86).
2) Download, install and configure xfree86 with cygwin (assuming they've got the 200MB free for it). By the way, I know there is a version that is supposed to work without cygwin. It doesn't work yet, at least not right out of the box, and not with any instructions they give you.
3) Get them to use a non-windowing solution, i.e. VNC.
I don't really like any of those options, and that is why, for instance, there aren't a lot of X applications whose primary function is to be run remotely. Its why I won't develop any such applications - why I'm still sticking to using those less powerful gui kits like tcl/tk, swing and awt.
I yearn for something better than X, whether it meets your needs or not. If I could get a third of the functionality I get with a windowing environment, but also get those things, I'd be all over that in a heartbeat.
Re:To answer your question (Score:5, Informative)
Sure, and after reading them, it becomes very clear that they site problems that are either no longer true or are just plain wrong. I was unimpressed with such papers.
1) Pay a lot for a decent X server for Windows (by decent, I mean that it doesn't put all X connections inside one Window with a fixed size, but rather creates Windows each time a call is made - unlike Cywgin xfree86).
2) Download, install and configure xfree86 with cygwin (assuming they've got the 200MB free for it). By the way, I know there is a version that is supposed to work without cygwin. It doesn't work yet, at least not right out of the box, and not with any instructions they give you.
You haven't done very much research, I see. XFree86 for Cygwin is excellent (90-95 MB, actually), and it features both a windowed mode and a rootless mode, which was added a couple months ago. I replaced 40 clients at work over the past two weeks that had been running an outdated version of Reflection X on NT 4 with Win2k and Cygwin/XFree86 (the Reflection version wouldn't even function on Win2k, requiring a $350 purchase per PC for the latest verison).
Re:To answer your question (Score:4, Interesting)
Re:To answer your question (Score:5, Informative)
Re:To answer your question (Score:5, Insightful)
However, as a platform (a standard for application creation) X is sub-optimal for users and developers.
The value of a standard comes not only from what it allows you to do, but what it forbids.
Suppose I write 3 programs to perform the same tasks under different GUIs: Microsoft's, Apple's OS X Quartz/Aqua, and X11R6. A Mac user can sit down without looking at the instructions and use his familiar old mouse motions, menu commands, and keystrokes with hardly a glance at the new stuff. A Windows(tm) user has nearly the same advantages. The icons for the same feature (Save, Print) look exactly the same, regardless of the program.
Of course that's not the case for X programs. Whenever I sit down at a new X11 program, I have to spend a few minutes recalibrating the basics ("How to I copy/paste, again?")
Because X allows the developer so much freedom, it deprives the user of the ability to anticipate how a program will operate. "The program can do nearly anything" sounds like an advantage, until you try to predict what a program will actually do!
Note that a weakness of Apple and Microsoft's GUI systems is that the "forbidding" part of their standard often comes in the form of "law" [code-is-law.org] instead of "code". The taboos are enforced by developers getting chastised by the GUI vendor or the public when a non-ituitive program is released.
A weak method- the lag time for feedback is long, and if the offending developer [iarchitect.com] works for the GUI vendor, he might insert loopholes [apple.com] into the rules.). But it produces superior results to X programs, where the users lack an imposing rulebook to point to as formal justification for their complaints. Improvements may happen, but there's nothing forcing them to converge on one way of doing things.
Some common responses to this argument:
"You want a toolkit, not X"
Maybe so. If a user's desktop could only run one toolkit, she'd never see an unfamiliar interface. This has the problem of discarding pre-existing programs, but argument-by-popularity is a logical fallacy (I'm talking about what solution would be best, not cheapest short-term). Better than using a single toolkit, though, is somehow allowing the application to be written independent of toolkit, and obeying whatever HCI conventions a particular user enjoys. PicoGui [picogui.org] tries to do this.
"No one can be sure what the best interface is. Keeping flexibility gives us power."
In theory it does, but at the expense of accessibility. Too often it means that developers who don't want to be "HCI Researchers" find themselves wrestling with UI code that's entangled their applications.
PicoGui (and other "next-generation" UI systems) attempt to resolve this by keeping the application programmer further from the UI code than is traditional. (They haven't been totally successful yet)
He can't mess with the per-pixel alignment of buttons, because that's outside of the application's control.
This is fundamentally better than the way Apple and Microsoft's traditional Human Interface manuals have worked, because enforcement of the rules is done not by humans (punishing programs that act wrongly) but by software (doing the work for you, so it's guaranteed to do it right).
Re:To answer your question (Score:4, Interesting)
Suppose you pick a non-biassed example and choose Microsoft GDI, Display Postscript, and X11R6. Comparing a high-level GUI toolkit to a low-level windowing system is an ineffective way to prove your point.
Re:To answer your question (Score:5, Interesting)
This same problem happens in discussions about Linux. The strict definition is an OS kernel, but "Linux" has also come to be a blanket term for the whole family of Open Source operating systems that use that kernel. "Operating System based on the Linux kernel" is too long to use in everyday speech, so it gets abbreviated down to "Linux". ("GNU/Linux" is also too long, apparently)
So then, when someone attacks Linux (the broad definition), defenders can point to the specific definiton and dismiss the complainer on the basis that he's uninformed. When this happens, the debate is cut short, without a fruitful discussion of the merits of the problem.
Back to your point. You mention that for Apple's Aqua and Microsoft's GUI there are corresponding lower level APIs: DPS and GDI respectively. But this raises the question: What higher-level system corresponds to X11R6?
There isn't one. Or there's much more than one (Xt, Athena, Motif, Qt, Gtk, XUL, Fltk, WxWindows, TK...). Neither of those answers is useful as a starting point of discussing new GUI enhancements. You can pick any one of those toolkits and consider improving it, but then you're just addressing a fraction of all users (although maybe hoping that your favorite toolkit will rise to dominance above the others).
GDI and DPS are each found inside of one and only one GUI framework (architexturally a stack of blocks, instead of the branching tree of stuff that builds on X11R6). That's a consequence of monolithic developement instead of open systems, but it makes many things simpler on the users. How do you resize a window in Microsoft Windows? The answer is straightforward. How do you close a program in MacOS X? Another simple answer.
Neither of those operations is defined for X.
Only application developers are ever aware that DPS and GDI exist- they're completely hidden under the GUI. But users of X11R6 are frequently reminded of its presence. "Why isn't your program working? Did you check the DISPLAY variable? How about the xhosts? Ok, lets look at the MIT Magic Cookie..."
The world of Unix-like software can never have really great GUIs until X is invisible to average users. Maybe this means X has been supplanted by another system, or that it's just been relgated to the status of a device driver.
It's true that the competitor to PicoGui isn't X, but higher-level protocols. However the headline "An X Alternative" is not incorrect. Someday X's position as the premire "Unix GUI Application Development Platform" will be supplanted by something like Gtk, Fresco, or PicoGui. Then developers will begin to release software which runs on $NEW_DISPLAY_LAYER, rather than X directly. (Even though $NEW_DISPLAY_LAYER might still use X11R6 as a backend)
Someday a better UI environment will come around, when the only program allowed to connect to my X server is a single process from $NEW_DISPLAY_LAYER. It will enforce on applications the appearance and behavior that I want them to have, rather than leaving it up to individual authors.
You are wrong (Score:3, Interesting)
Also it is quite possible that X can suck in it's own ways even though a low-level protocol is a good idea. The fact that X is bad does not prove that every single part of it's design is bad.
First, plenty of toolits are on Windows. I recieve about 10 times more interest from Windows programmers who do not even know how to run a file from a command line for fltk than I get from Linux users. Also you can easily tell that virtually all large graphics systems and some of MicroSoft's own work (Word, for instance) do not use their "toolkit".
Also if X had been a "toolkit" like you seem to want, it would have been the Athena toolkit that existed in 1984. I'm sure the fact that everything is drawn in two colors (black & white, which a "configuration" that reversed them) would have been deeply engrained into it. There would also be those lovely scrollbars where only the middle mouse button did what you expected.
Fortunately this did not happen. All of X's mistakes are because the graphics were designed in 1984 (or earlier, really). But oddly enough bad graphics *can* emulate stuff that was not imagined 20 years later, so X is still working. Bad toolkits cannot do anything.
Someday there may be a replacement for "buttons" and "menus" and "icons" that is far more user friendly (no, I don't know what, if I did I would be writing it!) and when that happens the people who wrote toolkits into the system are going to look as stupid and backward as the people who wrote record-management into the disk file systems.
What is needed is for the people who can to stop doing the easy and "fun" part of writing "toolkits" (I know, as I am also a toolkit author) and start doing the HARD stuff, like drawing an arbitrary transformation of an image with error diffusion, something we have known how to do since about 1987 but for some reason is not in any of the graphics systems even today. Drawing every single character in UTF-8 with a single call that takes a string would also be nice.
Re:To answer your question (Score:3, Insightful)
No one else was making the point. True, I didn't have time to write much. But a barrage of "X is fine! You just don't understand X" posts had already started, and there was nothing better up to defend the idea of a next-generation GUI.
on Windows you've got OWL and MFC for starters
Does anyone really use OWL anymore? You're sure not going to earn a "Optimized For Windows XP [microsoft.com]" logo with those kinds of buttons!
you're misunderstanding the scope of X11
The (limited) scope of X11 is the problem.
But you can't argue that X11 needs to be supplanted by GTK.
Like I said, X11 is filling two roles. One role is that of a protocol, and it's fine there. The other role is that of a platform, and that's where it needs to be supplanted. Sure, we'll always have "Freedom of Choice" in that old/alternative source code won't just evaporate. But the only way the user-computer interactive process can become truely better (better than today's X11 desktops, and also the Macintosh and Microsoft offerings) is when someone creates a sufficiently powerful abstraction that application programming and GUI programming can be completely disjoint. And yes, good abstractions are hard, and PicoGui is really just a tentative step along the way, but developers need to explore this terrain if we're ever going to get a better system.
(X11 compatibility can of course be retained as legacy support for a long time)
The proper solution is to make all the higher-level widget sets interoperable. That's a harder problem.
Since PicoGui is not a widget set, one way to approach that problem is to write all widget-sets as PicoGui themes.
Re:To answer your question (Score:4, Insightful)
I don't know. Nor do I care. I made the point that other platforms are not immune to the "too many ways of doing things" disease. I really don't want to go off on an irrelevant argument about the popularity of the example I gave.
The (limited) scope of X11 is why X11 still exists. If X11 had tried to dictate appearance and behaviour and colour schemes and graphics formats - the level of detail that you would seem to like from X11 or its successor - then it would have been a dead project within 18 months.
Let me expand on this point. There have been 100s of competing GUIs from 100s of vendors. All incompatible. All aimed at different form factors with different design goals. All very different in terms of user interfaces and programming interfaces. But most of them share one thing in common... nobody uses them anymore. What people wanted from GUIs changed quickly and many of the "bare to the metal" GUIs couldn't evolve fast enough.
X11 wisely chose not to dictate the form factor, or the user interface, or the programming interface. X11 provides you with the tools so you can build your GUI without having to write all the boring low-level stuff such as video drivers, event handlers, windowing operations, etc. You can simply concentrate on the GUI. So while GUIs change from year to year, there has never been a good reason to get rid of X11, because X11 IS NOT A GUI.
And as I said before, you've got no chance of that ever happening, so stop wishing for it. You might as well wish that everybody only wrote for KDE, or only wrote for CDE, or only wrote for GNOME. It's a waste of time wishing for the impossible. The proper solution comes from standards like ICCWM and XDND. No problems will be solved by throwing away X11 and hoping that everybody standardises on your favored project (ie, PicoGUI).
Re:To answer your question (Score:4, Insightful)
And what bad faith of you to do so, since your implication is that X is on a par with Win/Mac for standardization, and thus ease of use - or are you merely quibbling.
The (limited) scope of X11 is why X11 still exists.
No, inertia is why X still exists. Please, if you like, starting with your "100s", list the free and open (or even close) alternatives to X that withered on the vine out of anything other than the "good enough" momentum of people who were already using X.
many of the "bare to the metal" GUIs couldn't evolve fast enough.
I actually laughed when I read this. You live in a strange fantasy world, where the GUI has evolved at anything other than a snail's pace in the last 20 years. "Couldn't evolve fast enough." I think my garden slugs are evolving faster.
Truthfully, there is a tremendous advantage to a well-integrated, well-packaged and concise system that does GUI end-to-end. It saves a lot of work for end-developers and if well made requires the same or (I think) less work to "evolve" than X+frontend of the moment. It means programmers can do a lot more because things are simpler. You see, these "assumptions" aren't just good for users, they're good for developers too.
Nothing about X's choice not to meet all these needs was wise. It was merely expedient.
X11 IS NOT A GUI.
You seem to be willfully missing the point. We clearly know this already. And as has been said over and over again, this is why we need to reconsider it.
No problems will be solved by throwing away X11 and hoping that everybody standardises on your favored project (ie, PicoGUI).
Quite wrong. Unless you don't consider the failure of unix outside of the server-and-geek world a problem. Maybe you don't. Consider the monumental efforts of KDE and GNOME - and spend 10 minutes with a non-computer-user attempting to work with them. X and its legacy is fundamentally what's in the way - it's a big mess, even as a protocol, and the design decisions inside it percolate up to the very highest of the high-level interfaces built on top of it, usually wounding and crippling them. Unfortunately, there's a lot of elitism and snobbery in the unix and development worlds that keeps people from looking past it and imagining what could be better. But some of us remember the same kinds of folks arguing that the GUI itself was a fad, and a waste of time, next to the "good enough" CLI.
Re:To answer your question (Score:3, Interesting)
This is an interesting argument. Can you offer an example? I'd certainly agree that some X11 features were abstracted poorly. I would also agree that certain X11 features should never have been part of X11. But I'm having difficulty thinking of any problem with X11 that can't be solved with an extension. Some of these extensions might be difficult to write, but I'm optimistic given the number of excellent and timely extensions to XFree86 in just the past 5 years. Consider...
Do you see why I'm optimistic? Features have never been - and I will boldly claim will never be - a problem for X11. Features are added quickly and relatively painlessly by extensions. The features are integrated into modern desktop GUIs within a year or two. This isn't rhetoric or hope... it's established fact from watching KDE and GNOME.
So the only problem with X11 that would worry me is something so fundamentally broken, so fundamentally unalterable, and so fundamentally ingrained in everything about X11, that fixing it would involve a complete replacement of X11 with something entirely new. I can think of dozens of niggling problems but not a single fundamental problem.
Re:To answer your question (Score:3, Insightful)
X alternatives never materalize (Score:3, Insightful)
Re:X alternatives never materalize (Score:4, Informative)
s l o w . .
Don't hold your breath.
What would it take? (Score:2, Insightful)
slow? (Score:4, Informative)
What video drivers are you using, and what apps/desktop enviornment?
Slower...yes. (Score:2)
Re:What would it take? (Score:3, Informative)
It's called the Direct Rendering Infrastructure [sourceforge.net].
How do you separate the two? (Score:2, Funny)
I mean, I often do favors for others. Most recently, a friend who attended grad school with me called panicking during the night and said that he couldn't feel his toes.
No one else was home at his house, so I had to walk him through the steps of logically evaluating the situation to determine the cause of the numbness in his lower appendages.
I didn't even think twice about whether or not to charge him. He was in great pain, so I billed his Visa card for $1,200.00 after diagnosing the problem -- he had left the window open and a cold front had arrived over the night. Without a blanket (it was late August), his toes had nearly froze.
True story. But after spending 14 years in grad school, I'm just not a nice guy anymore. I wouldn't think twice about charging people for services rendered. I even charge the people at Blockbuster Video when I return the video before it's due since I paid for the full time, and since they charge me for a late fee if it's not back on time. The best part is they usually compensate me for early returns!
Re:How do you separate the two? (Score:2)
Ease of Use (Score:2, Interesting)
Re:Ease of Use (Score:5, Insightful)
It's possible. Many X-Servers have been flaky from time to time. They write to low-level drivers, they get confused, they party over the PCI bus. It happens.
This is not the same as a "system crash."
If a computer is a workstation or client (not a standalone server), then the X server (or other GUI interface that gets pixels to the screen) is an integral part of the "system". From an end-user's standpoint, an XFree86 crash is virtually indistinguishable from a total system failure. ("All my running programs- they're gone!") Developers should treat it nearly as badly.
If an operating system allows one application to screw up and crash other running programs, we call it a faulty OS.
If one program is able to lockup an XServer so that other programs freeze and lose data, we should treat the XServer just as harshly.
Re:Ease of Use (Score:3, Informative)
Why picoGUI? (Score:3, Interesting)
Re:Why picoGUI? (Score:2, Funny)
Unified GUI services (Score:3, Insightful)
Re:Unified GUI services (Score:2)
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.
Isn't that something similar (with slightly different goals) to what Java tried with the original AWT? The idea was that the Java interface was a thin layer, but the underlying widgets were each implemented by the OS.
Needless to say, it failed pretty miserably, which is why Java later came up with Swing and the realization that to actually work everywhere, you have to implement your own code everywhere. It's all very nice to say you want a thin layer on top of standard services, until you realize that the "standard" services are not very standard from one OS to the next (in the case of Java) or from one window manager/widget toolkit/windowing system to the next (in this case). Those differences make it very challenging-- and, more to the point, messy and crufty-- to try to write a "thin" layer that can somehow interact with all of them.
It's nice in theory, but it doesn't really meet well with the real world.
-Rob
Re:Unified GUI services (Score:2)
So what... (Score:5, Insightful)
Re:So what... (Score:2)
Well, I for one do. This is not another desktop [kde.org] environment [gnome.org]. This is a new way to do graphics on unix. No more client/server. IMHO this could be a giant leap for linux on the desktop.
Re:So what... (Score:2)
Re:So what... (Score:4, Interesting)
Well, I don't have moderator points, but I will say that (again) we are missing the ultimate point. Open source software development is supposed to be FUN. They think this is fun, or maybe useful for their stuff, or maybe both. That's plenty. People who are having fun with it will "give a shi..". Everything doesn't have to be take over the world. Unfortunately this article put it in those terms, rather than "hey, here's a cool little project."
Two applications I find potentially interesting for this are a) GUI installers that don't require X (serious overkill) and b) usable GUIs on really old hardware - make an interface to a few apps in picogui, make a mini desktop, stuff it on a 386/486, and ship it off to a country where computers are hard and expensive to come by.
For my money, the reason to replace X is not speed, but more power and flexibility and clean design. Hardware takes care of speed. That's why I'm a fan of Berlin. But until Berlin is done, X is great. But so are cool projects like picogui.
Bad screenshots (Score:3, Funny)
When I first showed my wife Linux, the first thing she asked was "What do those eyes do?" My reply, "Some people use them as a status indicator for predictive multitasking thread optimizer, but mine just look at the cursor." "Cool"
You can pry X from my dead hands... (Score:2)
Nothing! What is this thing people have about reinventing the wheel?! I mean, even linux is revolutionary only in it's implementation of un*x, that's why people started using it. As much as people gripe, X-windows is pretty well designed for a gui. Preciesely because it dosen't do much, other than act as a glorified lackey for handling input and output, leaving the rest to other programs/libraries/widget-sets/etc. And it has proven to be flexible to meet the challenges of the future, let's not forget DRI [sourceforge.net] and xinerama and the like.
About the only thing X could be argued to be lacking in right now, is no good native support for vector drawing. But gtk's canvas, and I'm sure others do it well enough in 'user' space, that perhaps it wouldn't be justifiable to burden X with it, [asside from being a more universal API... but then again, who programs directly to X anyway, but widgetset creators?!]
Most important... (Score:5, Funny)
I don't see why we need this (Score:3, Interesting)
I find that a dubious design decision. I like the fact that I can have many different kinds of widgets and graphics under traditional window systems. For example, for handhelds, I can use something like FLTK, which is very light and does not have much in the way of geometry management, while on desktops, I can use something heavy-weight like Gtk+ or wxX11. Also, there is no widespread agreement of how widget layout should be handled in GUIs.
If you want a widget server like PicoGUI provides, you could easily add that between client applications and an X11 (or Quartz) server.
Eventually, X11 will get replaced by something, but among the current contenders (Windows GDI, Quartz, PicoGUI, Berlin, etc.), I don't see anything that has compelling advantages.
Re:I don't see why we need this (Score:4, Interesting)
1) Consistency, because all clients use whatever widget set the server does. By making the server modular, you can use FLTK for handhelds and GTK+ for desktops, and all apps will obey that decision.
2) Performance, because by interfacing clients and the server at a high level, you reduce communication between the two by a huge amount.
Re:I don't see why we need this (Score:3, Informative)
You make the assumption that putting the widget set into the server ensures consistency, or that not doing it means GUIs become inconsistent. Experience with real-world window systems suggest otherwise.
Mac OS X ships with multiple widget sets that are consistent, and people use many more to develop on it. Windows, too, ships with multiple widget sets, and there are many additional GUI toolkits in use for Windows. Yet, most people don't even notice. That's the way GUIs work.
Performance, because by interfacing clients and the server at a high level, you reduce communication between the two by a huge amount.
I have seen no practical indication that client/server communication is a bottleneck for X11. Why "optimize" something that doesn't need optimizing? Furthermore, X11 already takes care of many widget-related issues, like geometry management, bit-blitting of retained pixels, and event dispatch. Basically, in X11, if you open a subwindow and draw some text on it, you already have a widget, and you can eliminate almost all client/server communications through backing store.
Re:I don't see why we need this (Score:3, Interesting)
But neither Windows nor MacOS enforce assumptions at the system level. The reason why toolkits look alike on those platforms is because toolkit developers choose to make them look alike.
According to the X mailing lists, this is the real reason people think X is slow. Applications just aren't written for high-performance drawing.
It's not an issue with applications, it's an issue with toolkits: Gtk+, Qt, and Swing are just not designed for maximum efficiency under X11. Since they are more than fast enough on current machines, that doesn't bother anybody other than people who just hate X11 for no good reason.
Applications just aren't written for high-performance drawing.
Even in your optimistic scenario, PicoGUI only speeds up the drawing of widgets, not other application drawing. But toolkits draw the widgets. Therefore, if you want to speed up the drawing of widgets under X11, just use a more efficient X11 toolkit.
By putting the widget set in the server (and ideally, the entire presentation layer) you can have one well-optimized set of code, so applications can be implemented in a straightforward manner and still have high performance.
You can have "one well-optimized set of code" right now, by using a more efficient widget set under X11. In fact, X11's windows are almost complete widgets in themselves already--X11 isn't all that different from PicoGUI.
And people will not stop writing Gtk+, Qt, or wxWindows code just because PicoGUI comes around, so those toolkits will do even worse on top of PicoGUI than on top of X11.
Re:I don't see why we need this (Score:3, Insightful)
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.
Replace X? Why? (Score:2)
web browser (Score:2)
Not much. But then again... (Score:3, Interesting)
X is a big dumb slow ram hog that's impossible to configure without a lot of help and with no consistant look and feel thanks to the proliferation of widget libraries. Something smaller faster and more elegant with a more consistant interface would go a long way towards making me switch from using Windows as my GUI of choice.
On the other hand, there are a crapload of apps for X and everyone COULD standardize on a widget library and a window manager. Also as computers get faster and storage gets bigger and everything gets cheaper a lot of X's performance problems are sort of going away, kind of like what's happening to Java. The remaining issue (configuration) has come a long way too, so maybe there is no need for an X replacement.
I guess I'm always willing to give something new a try, but the real deciding factor is always software availability. For years MacOS was technically superior to MS-DOS and later Windows, but whenever I asked someone why they didn't switch the first thing they said was "there's no good software." Eventually I came to agree and switched to Windows myself (and also Linux). People will only use PicoGUI if there is good software for it, and nobody will develop for PicoGUI unless there are users. It's a chicken or the egg issue. Of course Linux and KDE and others have been in that situation and now are quite popular. So what it would really take to get many people to use PicoGUI would be a concerted effort on the part of a commited group of developers.
That's my $.02
Re:Not much. But then again... (Score:3)
So is Windows' GDI32.exe. So is OS X's Quartz. If you want to believe either is a memory featherweight, I got a few investment ideas for you...
impossible to configure without a lot of help
The exact same can be said of both Windows and Macintosh -- and PicoGUI. Configuring hardware is not, nor has it ever been, easy. The only reason OSX or Windows seem so 'easy' to configure is that Apple or Microsoft wrote programs to provide "a lot of help". X doesn't have anywhere near the amount of automation built-into it. PicoGUI doen't auto-configure itself either; with a few exceptions, the only way you'll get PicoGUI to work is through X.
The thing here is that X is just a graphics subsystem. It does not contain configuration utilities, or its own widget sets. Strip off the (many, many) shiny "computer administration for dummies" configuration programs, and you've got the ease-of-use of Linux. (Actually, linux is probably much easier to configure manually than GDI32 or Quartz would be.) It isn't a fault of X -- Nobody's getting paid $90k a year to write these config utilities. Font configuration problems? What?!? You mean you have to do it yourself!!! Oh no!!!
Look - on some level, there will always be a need for people who understand how to configure GUI systems by hand, manually -- somebody has to know how to do that if they are to write a 'config for dummies' applet. Don't blame your refusal to learn on X. If you find the current system inadequate, then fix it yourself. Around the time you figure out how to make a spiffy auto-configure, you'll most likely have gotten past the need for such a utility, and won't be as motivated to 'fix' a system that was never really broken -- just misunderstood. (Of course, it helps that when people try to explain how confusing X is, and then try to straighten things out, usually end up spouting off incorrect information -- they're confused because they never knew the facts to begin with, and others take it as the truth, and the cycle repeats, only worse each time, until X has a terribly bad wrap.)
Something smaller faster and more elegant And you compare X to GDI32 or Quartz Extreme? They aren't smaller, or faster... It's all in the graphics driver itself there -- not the GUI system. All of this eye candy people crave requires a great deal of resources -- Anti-Aliasing, Themes, gradients, pixmaps -- all of them take significant resources, and ever-increasing numbers of processor cycles to execute. Hell -- Microsoft's own 'theme management' for WinXP is several times slower & larger than many of the alternate themeing systems (such as StarDock's WindowBlinds) Quartz offloads everything that it can to the video card-- earlier releases (before 10.2) used the same 'primitive' drawing techniques that X uses, with similar performance.
As far as elegance goes -- Elegant to use, or elegant to program? Win32 widgets are a nightmare to program. I've not had a chance to do OS X, but I understand they are elegant. And X widgets (at least QT and GTK) are quite elegant to program.
As far as 'elegant looking' -- blame the writers of the applications.
Most commercial apps have graphical design teams who specialize in GUI design placing the widgets. Linux apps have a programmer placing them in a way that seems logical to him/her, and attempts to match it as best as possible to various GUI standards (such as Apple's or KDE's).
Standardization on the GUI is something that has met rather vehemant opposition -- look at the KDE-GNOME wars!!!
But X itself is not the problem. X only provides the ability to have a keyboard, mouse, and graphics. Everything else is higher-level, and not a part of X.
I like what I see. (Score:2)
Looks like there are a few graphical problems to fix however, like scrollbars (The bar part of it seems to overlap the arrow buttons, shouldn't happen), and the square behind buttons being white.
Re:I like what I see. (Score:2)
'X backward compatibility' (Score:3, Insightful)
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.
Re:'X backward compatibility' (Score:3, Interesting)
I do think what is needed is a new complete rewrite of the Xlib/Xprotocol layer to be modern. I do not like the fact that they keep adding calls or user-level libraries to make up for X's lame graphics capabilities. A clean lower level would be much easier to understand and debug.
The existing X interface can be emulated atop it. Most people would be happy with just an emulation Xlib that talks to the server by translating the old calls to the new ones. It does not have to be accurate (for instance it could tell the program 32-bit TrueColor no matter what the hardware does, and I'm sure the fonts will be named all different and be UTF-8 only, and it will not run any existing window managers. But this would allow you to run your old programs on the new system.
It may also be necessary to make an "XServer" for remote programs to talk to in X-protocol. This could be an independent program that translates the protocol to the new system. Without this you could not run programs from other machines that think they are running old X. This is not so important however.
I do not think a replacement for X will be successful without an Xlib emulator. This does not really preclude any design ideas. Even people who want widgets in the server (an idea I don't like, but there are arguments for it) will certainly provide the ability to create a blank window-sized "widget" and for a program to detect where the mouse is clicked and draw arbitrary graphics. X programs can use this for emulation. Yea, it won't look like the spiffy new widgets but at least the old programs work, which is really all that is needed.
All these systems have to realize how important Xlib emulation is needed and must work on it immidiately so that it is available the first day their system is available for use. Otherwise they will fail.
Compelling reasons for me... (Score:2, Interesting)
What PicoGUI is and isn't (Score:5, Interesting)
PicoGUI is designed with a lot of goals in mind, but for me the largest goal is scalability. I'd like to be able to run one app, with minimal code changes if any, on a PDA, desktop, cell phone, phone, toaster :)
There are also a lot of architectural decisions PicoGUI makes that lends itself to easy and consistent solutions for common problems other GUIs have to deal with. PicoGUI has a theme system that manages everything from drawing the widgets to laying out entire application UIs, all with surprisingly little code. It has a video driver architecture that handles raw framebuffers, accelerator cards, and even esoteric devices like ncurses rendering or text-mode LCDs. PicoGUI's widgets are designed with more of a UNIX philosophy- small but powerful widgets that can be combined in nifty ways.
I didn't originally intend PicoGUI to be a primary GUI for desktop computers. I started it for a PDA project I was working on. But, given how its architecture lends itself well to scalability, it could soon be a good GUI for desktops. Recently PicoGUI gained the ability to run in a "rootless" mode where it acts more like a widget toolkit than a complete GUI. Once PicoGUI has drivers for DirectFB or some other acceleration backend, and a way to run X apps in an emulation mode, it should be able to completely replace X.
In my opinion, the biggest stumbling block to replacing X on the desktop is having accelerated video drivers that work on other GUIs. I've talked to X developers about separating the video drivers into a layer that can be used directly by projects like PicoGUI, GGI, and Fresco, but they had no interest. From what I've seen of X developers, they want all the world to run in X.
Re:What PicoGUI is and isn't (Score:5, Informative)
It is almost certainly not worth it to try porting Gtk, Qt, or anything else at the widget level, as PicoGUI's widgets are designed differently than most GUIs' widgets.
x is a generalization (Score:2)
You can't really replace X (Score:5, Insightful)
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
--
Re:You can't really replace X (Score:5, Insightful)
You say X is so low level it doesn't make sense to criticize it, but I think X has actually taken the worst of both the high-level and low-level worlds. X is low-level enough that you don't get any application consistency and you still end up sending individual graphics primitives over the wire. But, it's still high-level enough that it makes it hard to do some types of graphics operations. Yes, I know about RENDER. Putting aside all arguments on X's architecture, that still doesn't make it any easier to do things like blurring, multiplying two bitmaps, or rotation.
Re:You can't really replace X (or windows) (Score:3, Funny)
Basically, everything depends on Windows, so you can't really replace Windows and maintain backwards compatibility. In order to have backwards compatibility, you would need to provide all the services provided by Windows, so you would, in effect, just be writing a new Windows.
If you really want to replace Windows with some other system, then you could probably get pretty far by just porting MS Office and Internet Explorer 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 Windows. It's just an abstraction for hardware that allows you to effortlessly run multiple programs. 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 Windows is.
For example, if you don't like the performance, then that is a complaint against the specific hardware or drivers you are running, not against Windows itself.
If you don't like the program crashing, then that is a complaint against the programs you are using (Office, IE, ICQ, etc.). This has nothing to do with Windows.
As far as features go, if you really want a feature and Windows 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 Windows is inherently problematic. I think that most complaints about it are misplaced, and should be directed elsewhere.
Furthermore, when people talk about replacing Windows, they seldom seem to appreciate the benefits of allowing multiple applications to run on screen at once. This is one of Windows's strongest points, yet most people seem to want to replace it with what amounts to software rolled up with a kernel.
Well, that's my $0.02.
What's next? (Score:3, Funny)
viGUI? emacsGUI?
Some "inside" information (Score:5, Informative)
Some information for the curious:
- Micah (the lead developer) compiled some info at http://picogui.org/wiki/view/Main/PicoGUI [picogui.org] and http://picogui.org/wiki/view/Main/FAQ [picogui.org]
- it is not X. It cannot run X apps. No way. Period.
- it is very early in development. I use it for a few things, specially in my PDA, but it's a living-on-the-edge experience.
- there are client libraries for C and python; there are the beginnings of a tcl library, dunno how usable, and an old perl library which needs work. There is also a waba (java) library, but I don't have any idea of its status.
And now my answer to your question, IMHO:- a terminal widget that runs things like mutt, emacs, lynx|links|w3m
- a web browser; porting mozilla sounds like the obvious choice
- and, of course, apps.
Then again, I'm not sure X has to be replaced. But you're not talking about replacing, you're talking about alternativesHow long before a cease and desist ... (Score:3, Funny)
Come on guys, lickable buttons and pin stripes are so last year
When does the OS building stop and the work start? (Score:4, Insightful)
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 [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.
No. X is here to stay, just like it should be (Score:5, Insightful)
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
widget tunnelling (Score:3, Interesting)
Removing flexibility for better bandwidth = too many people pissed off! Open Source software supports niche users, and no one is ever going to be able to get around that fact.
Speed is fine IMHO. Maybe (don't know, don't care - I've spent too many hours customizing kde's look&feel settings) X is slower than the Windows GUI, but other factors (gcc + better OS) apparently make up for it, because I find LGX to run faster - of course, that's just my experience.
I don't see why "widget tunnelling" instead of X tunnelling can't do the same thing picoGUI does as far as bandwidth is concerned. So someone figures out how to tunneling Qt and gtk in addition to just basic X info and magically, X defeats bandwidth consumption by taking its "flaw" dependency on toolkits and turning it into the solution.
Sure, speed probably won't get a boost - but on my 128mb RAM P3-733, speed is fine, and an unnoticeable increase in speed is not worth the loss of the personality we can add to our interfaces on X today.
OTOH, I have no idea what I'm talking about.
X is fine (Score:5, Insightful)
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?
Re:X is fine (Score:3, Insightful)
The purpose of X is to allow you to draw things to the screen and manage windows (drawing viewports). X is not a GUI, in the same way that the GDI is not a GUI, and neither is Display Postscript. Ditto for the Linux framebuffer. Enforcing UI standards is the job of the toolkit. The fact that we have 2 major widget toolkits is kind of unfortunate, but actually other operating systems have this issue as well.
For instance Microsoft Encarta has its own widget toolkit. So does MS Office. On the Mac side, the whole brushed metal look that appeared a couple of versions in is another good example - did Display Postscript enforce the beige stripes? Of course not, that wasn't its job.
Why keep re-inventing the wheel? (Score:3, Insightful)
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..
Different design (Score:3, Interesting)
Like Fresco, the idea is to put the widgets and window management on the server side. And why wouldn't it be there?
- it does NOT mean you can't replace your widgets with others with a different behaviour, look, feel, whatever!
- picoGUI is scalable: not visually scalable, but the same program can display something using text-only lcd, console, or full-fledged graphics - and in all cases it's usable and adapated!.
- it's about separating representation from content!!! isn't that what web developers have been struggling with too? (HTML + CSS)
- the display hardware is on the server side, so having as much as possible on the (display) server side will give you a lot of opportunities to take advantage of hardware acceleration (see Fresco, that uses opengl HW acceleration for everything, including widgets etc etc)
There's always a strong resistance against change - I wish people would be able to look towards the future a bit more. And in any case, we're not dropping X just yet, it's just about exploring new alternatives, that might end up technically better (isn't that what Open Source is about). These projects are not about making Yet Another Window Manager. They're not about eyecandy either.
The fact that more and more projects (Fresco, picoGUI,
Please, just read up a little bit on both the projects I've mentioned.
A simple user perspective (Score:3, Insightful)
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.
Too high alimony prevents divorce from X (Score:4, Insightful)
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.
This might be cool, but .... (Score:3, Informative)
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, 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 is fine, but X really is a very cutting edge and flexible system that needs a few "ease of use" apps added to it.
Good Bad X (Score:3, Insightful)
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.
Re:It looks nice... (Score:2, Informative)
no, you shouldn't (Score:2)
If you can live with that overhead, fine, use cross-platform toolkits. I use wxWindows myself and think it's a pretty nice toolkit. But you have no basis on which to complain about X11 performance or functionality if you hamstring it by using cross-platform GUI wrappers with it constantly.
Re:I like innovations but (Score:2, Insightful)
Re:X translation layer? (Score:4, Insightful)
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
--
Re:Speed (Score:2, Interesting)
Re:Speed (Score:3, Informative)
And how fast "could it be"? X11 seems to be faster than both GDI and Cocoa/Quartz on comparable hardware in my experience.
(any tweaking hints are welcome)
Most supposed performance problems with X11 seem to be due to the toolkits and desktop environment used. Gnome or KDE on X11 can be a bit sluggish on low-end machines Tweaking hint: use a different desktop environment.
Of course, you can also enable backing store by default in your X11 server, which is how a lot of other window systems achieve their slick look; backing store is disabled in XFree86 by default because well-behaved X11 clients shouldn't rely on it.
not quite (Score:2)
But, you are entirely wrong about X. X is pretty good. Most complaints about X are being addressed, and relatively quickly I might add. With Xft2/fontconfig, font rendering is now extremely good, easier/quicker to add fonts than in windows. Desktop resizing is being worked on, and I believe changing color depth on the fly is as well(I could be mistaken... I don't think most people consider that to be too important these days anyway).
As for Gnome/KDE, they are beginning to work together more closely to implement some standards for menus, icon schemes, etc. Also, once some of these things are worked out, Gnome development should increase quite a bit.
Things are actually looking pretty good at this point, many long-time complaints have very recently been addressed, and very well at that.
FWIW...
Re:My thoughts (Score:2)
Re:Damn all you naysayers (Score:4, Insightful)
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
--
Re:Why I love X and will defend it to the death... (Score:4, Informative)
With Fresco you get network transparency. We use CORBA to develop Fresco, so that's a free bonux. I know all those CORBA is bloated, jadajada, arguments, but I am confinced they do not apply to Fresco: We knew from the very beginning we will use CORBA and have taken its strength and weaknesses into account designing the overall system.
Anyway: Fresco is network transparent and it uses way less bandwidth then X. The protocol is so much more high level! The small demo we got only uses 1.9kBit/s to hold the connection with the remote server. I don't know any numbers for X, but VNC needs 800kBit/s when used to 'forward' the Fresco server to another computer via its protocol. It was using the same demo but with less then half the screensize the original server ran at. Not that the screensize does matter with Fresco. Of course I did the same things with the window (moved, rotated, shaded it, opened subwindows, etc.) using VNC to forward the display and running the Fresco server locally and having the client connect from the remote maschine.
Fresco allows for different 'WindowManagers' (of course we call them 'DesktopKit'). Those are loaded into the server and are not normal clients like in X, that's the basic difference.
You got a good point wrt. the decades of testing. Obviously neither PicoGUI nor Fresco can give you that. But then there's less testing needed: The servers have much less code. All the graphic-card handling stuff is separated out into libraries like SDL, GGI or whatever. Those have been thouroghly tested for a while now, makeing that critical component rather relyable.
Hardware support is not as bad as you imagine. Since neither PicoGUI nor Fresco (nor any other project in a sane mind) is writting graphic drivers themselves! There are excellent libraries, kernel modules, etc. around to do that. If there are only X-drivers, then you can still run on X-windows (it spoils the purpose of replacing X, I know:-) till one of the farious 'rip the drivers out of X'-projects is successful. There are several of those arround even now.
Finally you use the if it works, don't fix it argument. I like that, but obviously X does not work or there wouldn't be so many X-extensions getting actively developed. As I see it, you can either extend X (to Y or whatever you want to call it) or work on something new like PicoGUI or Fresco or some other project. In both cases you end up with a system where applications developed for it will not run legacy X-Systems (without considerable efford of the Programmer/Toolkit writer). Once you use an extension your application breaks for X-without-said-extension. So baiscally you end up with a system not 'forwardward' compatible with vanilla X, independent of wether you extend X or write something new. X-with-extension is of course backward compatible, but a compatibility layer can be added to another system later if need be. That's a lot of work, agreed, but the very simple case of just letting a X-server run in a window was allready demonstrated in Fresco.
Regards, Tobias
Some URLs you might find interessting: the Fresco Homepage [fresco.org], a short comparison of Fresco and X [fresco.org] (the server is slow, please bear with it), finally a page listing among other things Other GUI Projects [fresco.org] I found to be interesting for various reasons (both dead and alive;-).
Re:See also: XWT (Score:3, Informative)
Wow, PicoGUI is pretty impressive.
Yes, but it's fundamentally different from XWT. I would not choose PicoGUI for an intranet. Hell, I don't think I'd choose PicoGUI for an embedded project. They decided to use their own protocol for server/client communications, which is something I don't understand/agree with. It's YAP - Yet Another Protocol. Yes, XMLRPC would have a larger overhead in terms of larger message size and a mini XML parser, but they could have used straight HTTP GET/POST, CORBA or something smaller and already out.
I also can't give PicoGUI to a web monkey and get them to design impressive widgets and therefore apps with it.
I'll stick to XWT, thanks. :-) And for embedded I would probably choose microwindows or maybe even fresco. The integer-only aspect of PicoGUI is nice but the reality is that anything that has a display requiring a more complex GUI will have enough horsepower to drive one of the bigger windowing toolkits.