Ask Slashdot: Comparing the GUIs 539
Hanno asks:
"It seems to me that some folks think that X is outdated and should be replaced. I know of the Berlin project and the announcement of Amiga to use the Linux kernel seems to be another candidate of a non-X windowing system (if the new Amiga is ever to happen). I wonder about the reasons. With this question, I don't want to start a discussion if X should be replaced or not, but I only want to find out what's bad about it and where other solutions are better. And I don't want folks to simply bash X, just some solid, technical reasoning. Which other windowing system (on which other operating systems) are out there and what are their pros/cons compared to X?" All I ask is that you folks PLEASE restrain from the rampant advocacy. I think this is a good question that might start a thought provoking discussions. Have at it.
Re:Effects of abondoning X (Score:1)
How IMLIB interfaces with X I dont know, I expect it has some direct connections to help speed the process.
QT is availible for other operating systems, so rewriting it for another windowing system should be easy
Re:My Biggest Problems with X (Score:1)
Re:My Biggest Problems with X (Score:1)
Re:My Biggest Problems with X (Score:1)
1) Bullshit. Anyone can join XFree86, who wield substantial influence.
2) X consortium tried to make X11R6.4 proprietary. They failed. Want to know why? Because they didn't want XFree to fork their own release, as they knew that everyone would just ignore the X consortium.
5) and 7) (which are the same point, really).
It will be as hard to push Berlin onto unwilling users as it is to push gtk+ / QT / whatever onto unwilling users.
Yes, you are biased on the subject. Please stop spreading lies about X.
Re:Anyone know lots about X? (Score:1)
Anyone know WHY X feels slower?
IMHO X feels slow because you can see separate widgets being redrawn in cases when Windows does double-buffering that works simultaneously on multiple widgets in the same window. Redraw time may be the same, but looking at static picture that changes at once makes it feel that the whole process happened faster.
In my case i have not much use for network transparency, and pcanywhere appears to do this much better anyway without the transparancy.
This happens because you use relatively high-latency or slow network without lbxproxy or compressed ssh X forwarding.
Re:Also Wrong (Score:1)
11 is not a version number.
#define X_PROTOCOL 11 /* current protocol version */ /* current minor version */
#define X_PROTOCOL_REVISION 0
Re:The X protocol is too slow and chatty (Score:1)
If I remotely start Applix-UNIX on a SUN it runs faster than a remote Applix-NT. Whether this is just my imagination or real, I dunno. I don't think this is important anyway, since it's always subjectivity that counts.
Most likely you run it over low-latency line, forwarded over ssh X proxy in compressed mode while other have high-latency line and no proxies.
Eye candy and remote display (Score:1)
When you say folks think that X is outdated and should be replaced, that doesn't really say anything about what's wrong with it. Yes, X is very old, in computing terms, but I think its longevity has proven something about its incredible capability. Not to mention, nice projects like GNOME and KDE have definitely alleviated the ``ugly and difficult to use'' situation.
Despite any problems I've ever had with X, all that goes away when I start a remote KDE session on my Windows box using the MicroImages X server. The whole remote display thing is pure genius as far as I'm concerned. And using Xnest to get a session on another box is just rockin'. I don't even know about another windowing system that can do anything like this. If there is, I'd like to see it.
Re:X or no X (Score:1)
While it is a pity that X still lacks alpha channel and anti-aliased font support in the server, there is no reason that this cannot be added because X is fully Open Source. It also has the distinct advantage over its "challengers" in that it is not just vapor
X Window System (Score:1)
"X is the second worst window system ever invented.
Everything else is tied for first."
How true that is!
Re:fvwm kicks NT butt! (Score:1)
bwhahahhaha
NT has MDI applications
ahahhahahhaah
MDI microsoft invented MDI
i hate MDI. don't u hate it when ure running a word processor and typing in two documents and can't have a web page on top of the bottom document and typing from the top document?
I don't think so (Score:1)
Who am I?
Why am here?
Where is the chocolate?
Re:Antialiasing in action (Score:1)
Antialiasing doesn't sharpen anything. How can it? It's blurring it to make it smoother. And it's not a really trick of the human eye either. I've yet to see a computer graphics book that properly discusses the reasons for antialiasing. But a lot of that is because many CS types don't have a good background in Fourier analysis. The human eye, much like a monitor, is a point-sampling device. However, the human eye has much higher resolution than any monitor can hope to achieve. As a result, the lower sampling frequency of the monitor is visible as the so-called "jaggies" (high frequency transitions). Anti-aliasing attempts to reduce the impact of the jaggies by interpolating pixels to produce smoother (lower frequency) transitions graphically.
Re:Amiga will use X (Score:1)
You are correct, according to their recent technology brief Amiga is using X, and AFAIK they haven't changed their mind. This makes a lot of sense, and follows along with their plan to integrate existing technologies instead of reinventing everything.
I suspect that the only Amiga specific additions will be a Workbench window manager and desktop environment, and probably a new gui toolkit as well. It will be interesting to see if they base their stuff on Qt/KDE or GTK+/Gnome, or if they do something new. There has to be something new and different in order to interest people enough to buy, and it's probably a safe bet that they're going to concentrate on the visible elements, and leave the "below the surface" stuff alone.
TedC
Re:NeWS (Score:1)
John
Yes, X does have problems (Score:1)
--
1) X doesn't let you store "methods" on the server side. This means, for example, to draw a rounded box you have to draw 4 arcs and 4 lines. Need to draw another rounded box? That's another 8 drawing operations.
More modern windowing systems (such as Display PostScript) let you store procedures/methods on the server. You can create a method DrawRoundBox which performs the 8 operations. Then you send only 1 command to draw rounded boxes.
Server stored methods don't seem to be popular though. Probably because the server is far more complicated, needs far more ram, and in practice the overhead of the device independent language outweighs the benefits of reduced pipe traffic.
2) X uses a client/server model. All instructions pass over a single pipe. This is often (correctly) accused of being X's most significant bottleneck for performance. But most people incorrectly think the solution is to throw the pipe away.
However the pipe is only truly a hinderance when doing large bitblits, such as for games or doing an animation. The X pipe isn't a problem for any normal windowing operations (drawline, drawtext, createwindow) which constitute 99% of normal work.
If you think about it, all systems need some way of synchronizing multiple client requests to the display, and a pipe does so neatly. No serious windowing system uses clientspace functions which directly modify the framebuffer!
So the actual problem is how to keep the pipe but decrease the time spent copying pixmaps over this pipe. And remember, this is only for the benefit of programs which heavily blit the display (quake or xanim are perfect examples).
MITSHM tried to solve the problem by letting you draw directly to pixmaps on the server's side of the pipe, but you still needed to copy that pixmap into the framebuffer. No good.
DGA solves the problem by giving you full access to the framebuffer. You write directly to vidcard memory. There are no wasted copies. No problems with the pipe getting in the way. DGA wins.
Take note that MacOS/Win32 (the components which can be compared to X11) work exactly like X, with queued messages to communicate between clients + display and a direct graphics access mode for any apps that need high speed unencumbered blits.
3) Font handling in X is ancient. There isn't any way of arguing against this. X fonts were designed before scalable fonts gained popularity. Scaled fonts in X are a nasty hack onto a system which doesn't understand them.
Font and cursors were also implemented as bitmaps instead of pixmaps. This means you get black/white fonts with no anti-aliasing against the background colour. It also means that cursors look ugly and have limited capabilities.
The only solution here is to extend the protocol (ie start coding X12).
4) X has tonnes of legacy baggage. This can't be argued against either. XResources? Great idea, but don't seem to be used very much. XIntrinsics? Not a bad idea, no widget set seems to use them. XPrt? Exactly the same as GDI or QuickDraw printing, but nobody in the X world wants to use it. Support for DECNET? Throw away that baggage!
--
New extensions to X are fixing problems that have been caused by advancing hardware. DRI, XKB and Xv are all perfect examples of new advances in X that have loads of functionality and in some ways have been implemented better than commercial windowing system alternatives.
Most of the problems in X are honestly a problem with users and developers, or people's failure to understand that the X way of solving a problem is no worse than competing windowing systems. A good example of people not understanding the problem and the solution is evidenced by the neverending complaints against the X client/server pipe.
Re:MacOS X GUI (Score:1)
Re:X windows woes (Score:1)
--
rickf@transpect.SPAM-B-GONE.net (remove the SPAM-B-GONE bit)
Re:X's Client/Server Model (Score:1)
Re:My Biggest Problems with X (Score:1)
15 toolkits to run *8* apps? Is this New Math???
I use apps from different toolkits, and they're all pretty consistENT, but that's because the toolkits all mimic Motif. (Ever heard of it?
I'd personally like to see the Windows machine that can run flawlessly for 8 hours
Are you a Microsoft troll or what?
VNC==Suck ASS! (Score:1)
Actually, no...with XDPC ( I think that's the name) X over a dialup line is quite bearable...try doing much of anything over a dialup using VNC 8-P
X != Linux (was Re:The Advatages) (Score:1)
Quite frankly, it amuses me that, all told, despite the fact that EVERY connection to an X server is a network connection (even if the client is on the same machine) that benchmarks are comparable to Windoze systems.
I love the fact that X doesn't seem to be too much of a bottleneck for projects such as, say, Wine. I'd say, given more development (hint, hint, developers looking for a challenge
Re:For local performance, what about D11? (Score:1)
Would this be possible, what the original author of the post proposes? Would it be possible to add a special case for "localhost"? I've always wondered about this. I know that some of the paleolithic "network computers" used some kind of special localhost-only X server; perhaps something like this could be done...
Just idle ramblings.
Re:configuration mostly (Score:1)
Re:Criticisms I have read elsewhere... (Score:1)
X doesn't have anything to do with a user interface, it's a display server. I fail to see the point. Separating the mechanism of display from the things displayed is a *good thing*.
Too much versatility, leading to overly complex or impossible interprogram communication: "cut-and-paste never works properly with X (unless you are cutting and pasting straight ASCII text)
I agree, cut-and-paste with X is problematic. On the other hand, middle-button paste is way cool.
X is a non-extensible window server - in contrast to NeWS. X was based around the concept of a dumb graphical terminal, and it uses a lot of data to achieve that.
I don't know much about NeWS, but:
-> I like the iea of a fairly dumb display server. A display server just display
-> I'm not sure what you mean about non-extensible. That sounds like a problem with particular implementations -- there are various X extensions floating around (such as OpenGL, shared memory, and other things)
X programs have lots of nasty user interface problems, including X configuration.
That's an application problem, not X's fault.
X has bad hardware support - This is out of place, isn't it?
Sounds like a problem with particular implementations to me.
X isn't device independent, or maybe has a limited graphical toolkit? "Drawing arcs is probably impossible in a portable fashion."
They may be referring to colordepth handling, which is a definite problem.
Other criticism I've heard that the X protocol should take advantage of the locality if the client and server are operating on the same machine. This only makes much sense to me if the cpu overhead in dealing with the network protocol is noticeable; being able to transparently work from another machine is too nifty to throw away.
I really think this is a baseless comment -- I haven't heard any solid explanation of *how* X would 'take advantage of the locality'. Given that we have a client-server model, there must be a mechanism of communication; this is almost certain to be a stream protocol, and indeed X uses UNIX-domain sockets. These tend to be extremely efficient for almost everything; those programs that really need more bandwidth can use DGA or SHM. (even on a totally non-accelerated server -- fbdev -- SHM gave me a good framerate in the Myth2 demo)
In general, I feel that the UNIX-hater-handbook folks are a lot of people who were frightened by sh as a child or something and now feel that their purpose in life is to make snide remarks about UNIXy systems without offering any real suggestions for improvements. Which I guess is why it's called 'the UNIX Hater's handbook'
Daniel
Re:Printing (Score:1)
Gnome's solution here is (IIRC) to make the drawing canvas support multiple targets, one of which is Postscript to be sent to the printer.
That said, print support in Linux sucks.
Dnaiel
Re:I want my GUI to get more info from the app (Score:1)
Daniel
Re:Anyone know lots about X? (Score:1)
Anyone know WHY X feels slower?
Probably because X is just a normal process, while the Win95 GUI is partially integrated into the kernel. This means, in particular, that the mouse doesn't move until X is allowed to read from
In my case i have not much use for network transparency, and pcanywhere appears to do this much better anyway without the transparancy.
As I keep pointing out -- given a client-server architecture, no-one has suggested out a realistic alternative to some sort of stream protocol to communicate between them. UNIX sockets are extremely efficient for most cases, and SHM is available for things (ie, big pixmaps) which need more bandwidth. Once you have one stream protocol, though, you can generally support TCP with a trivial code change (most operations have the same semantics on any socket-based connection). The small bit of extra code won't be loaded into memory if you don't use TCP so it's not a loss that way. In other words, network transparency really doesn't hurt a local-machine situation much. Now, you can argue about what is transmitted over the network (some people think the display should be abstracted at the widget level..I don't, but..) but network transparency itself is a Very Good Thing. [tm]
Also, i think it would be a good idea to wait for V4 to come out before we switch to a faster windowing system.
AFAIK, X is currently at Version 11, Revision 6. (hence X11R6) So you're a little late
Daniel
Re:Hard to program? (Score:1)
The only thing I can see helping them is multithreading..message queues, AFAIK, aren't much different performance-wise than pipes/sockets like X uses and probably are worse than SHM (although I'm sure Berlin supports SHM) -- and I believe X can already hardware-accelerate everything if it chooses, no? (yes, I don't fit your criterion for replying, but the thing about message queues was too much
BTW, how is Berlin coming? Last I heard there was celebration because they'd gotten it to draw two overlapping triangles on the screen or something..
Daniel
Re:WYSIWYG (Score:1)
I think this should be the job of some document-rendering engine (like GnomeCanvas) rather than the windowing system. X is just a server to draw on the screen. Trying to make it replace lpd is a Bad Idea..
Daniel
Re:X Weaknesses (Score:1)
Wow, I must be really advanced..I seem to be running X11 here..
We have QT and the GTK, and Motif, and some other toolkits, but there's no unifying conceptual interface.
Whether this is good or not, this soapbox is (or should be) totally irrelevant to X itself. X's strength is its simplicity: it draws stuff. This is a fundamental concept in UNIX: make small, specific but general within a specific area, and powerful tools. If X is to be replaced it should be with another general-purpose display server, not something which thinks that the only thing you want to draw is a button.
Daniel
Re:Yes, X does have problems (Score:1)
I like this idea. Let's do it in Guile
No, we'd need a simple language (like the pseudo-assembly used for Mac SCSI) that can go into the X protocol..sounds like a great idea for X12..
2) X uses a client/server model. All instructions pass over a single pipe. This is often (correctly) accused of being X's most significant bottleneck for performance. But most people incorrectly think the solution is to throw the pipe away.
However the pipe is only truly a hinderance when doing large bitblits, such as for games or doing an animation. The X pipe isn't a problem for any normal windowing operations (drawline, drawtext, createwindow) which constitute 99% of normal work.
Thank you!! I've been yelling myself blue trying to explain this to idiots who think network-transparency explains the 'slowness' of X..
MITSHM tried to solve the problem by letting you draw directly to pixmaps on the server's side of the pipe, but you still needed to copy that pixmap into the framebuffer.
No good.
DGA solves the problem by giving you full access to the framebuffer. You write directly to vidcard memory. There are no wasted copies. No problems with the pipe getting in the way. DGA wins.
I disagree. Both are good in different circumstances. MITSHM, while actually adequate for games, is best for window-managers, graphics programs, and other systems that just want to display pixmaps. These programs don't need to be suid root or writing directly to display memory -- in fact, doing so would be a security and stability risk. SHM is a good comprimise for these. Games, on the other hand, would do well to use DGA.
Also, you forgot a third option: server-side pixmaps (in fact I think many window-managers and so on may use this..but I know Imlib at least uses shm) These work well, even over a network, for many programs -- especially games whose graphics are built using tiles (Freeciv for example
3) Font handling in X is ancient. There isn't any way of arguing against this. X fonts were designed before scalable fonts gained popularity. Scaled fonts in X are a nasty hack onto a system which doesn't understand them.
Absolutely.
New extensions to X are fixing problems that have been caused by advancing hardware. DRI, XKB and Xv are all perfect examples of new advances in X that have loads of functionality and in some ways have been implemented better than commercial windowing system alternatives.
I still haven't worked out how to use XKB/Xinput yet..
Most of the problems in X are honestly a problem with users and developers, or people's failure to understand that the X way of solving a problem is no worse than competing windowing systems. A good example of people not understanding the problem and the solution is evidenced by the neverending complaints against the X client/server pipe.
<AOL>I agree</AOL>
Daniel
Re:The real problems with X (Score:1)
X is a display server. It shouldn't be in the job of playing sounds. You need a sound server (NAS, rplay, ESD,
No 3D support. You can graft OpenGL on top of X, but then you've got this kludge with two APIs. The OpenGL API has nothing in common in the Xlib API. Weird. This should be unified.
No! OpenGL's strength is that it code for it can run on many systems. For example, it can be integrated into X..or Win32..or BeOS..or Hurd (well, not yet)..or..or..
Gross design. Does the protocol *really* need that many things in it? Can't we abstract some of that into a higher layer? Ugh.
My impression is that it is intentionally general-purpose and low-level; it's a protocol for drawing on the screen. Widget sets are for higher-level operations. (there are some interesting ideas of 'widget servers'..berlin being the most obvious one..but I don't think you can cut out the low-level stuff without hampering the client's ability to decide what to do)
Daniel
Re:Areas for improvement (Score:1)
And from what I hear other people saying about the protocol, there is some room for simplification.
I'm generally careful about what I hear people saying..there are always people who dislike a system and then come up with explanations. (not that that's necessarily the case here, but in general
Efficiency. The protocol needs to make better use of information already sent. Invalidate-areas would be great. Additional primitives to do basic stuff like BitBlt could help things along.
Maybe I'm confused, but Expose events already give the exposed area and there is a pixmap-copy operation unless I miss my mark..
Common controls aka widgets. You shouldn't need a toolkit to draw the standard user interface. There is a lot to be said for a few simple controls built into the standard. (This might be a "layer" issue--do they go in the window manager, the toolkit, or the GUI?) I think widgets belong in the GUI so every programmer can depend on them being there. I've seen 10 different shapes of buttons, 3 major types of scroll bars, etc. etc. Make it standard, so the programmer doesn't have to worry about it, and the user understands what they see!
Repeat after me:
X IS NOT A GUI!
X IS NOT A GUI!
X IS NOT A GUI!
X just draws stuff on the display. Agnosticism about GUI style is one of the things that makes it so flexible.
Daniel
Re:audio and other "local" resources (Score:1)
Daniel
Re:Everything we'd need in a potential replacement (Score:1)
Um. A server is something which accepts connections, takes requests, and Does Stuff (possibly returning information to the client). This is exactly how X works: a client conencts to the server, requests that the server do things for it (in this case, draw on the screen), and the server does it. There's nothing backwards about this at all.
Daniel
Re:X doesn't save state. VNC does. (Score:1)
Daniel
X is orthogonal to "human I/O" (Score:1)
No. That's Windows thinking
And I still want to be able to play audio from another machine without running X.
Daniel
Re:Criticisms I have read elsewhere... (Score:1)
Which distribution are you using? I think Debian ships them either as modules or compiled in (I think XFree doesn't support modules yet so they're probably compiled in)
Hardware acceleration/locality: Playing Quake2 over 10baseT is awkward; that's an area where client/server could definitely use an intelligent terminal, and avoiding streaming over a socket if possible (yes, bypass client/server entirely). It's a bit of an extreme, I know, but video and games should be no challenge whatsoever for Linux and X.
Video and games can use OpenGL, SHM, DGA, etc to bypass the usual mechanisms. SHM and DGA speed up blitting on the local machine; OpenGL (as you know) provides a graphics-drawing interface with much support for hardware accel. The really nice thing about OpenGL is that (er, I think) it can actually (!) be run network-transparently; I don't know exactly what sort of performance you get with (eg) Quake but some modeling programs at Brown run quite nicely over the LAN.
I have been wondering how multimedia (specifically, video) can be added to Linux and X. Streamlining seems necessary to me; a video extension, perhaps? Or a window manager (see NeWS) that handles different protocols? Or would you guess that shared memory can handle these efficiently? I just want to see the multimedia capabilities of Amiga added to Linux, and I'm curious about what is preventing that.
I think that things like DGA/SHM and DRI can help a lot. Since with DGA you're basically writing to video memory directly, you can't speed up much more than that
Daniel
Re:X's Client/Server Model (Score:1)
That is about it.
Ha! Try ``an order of magnitude.'' Where did you get this idea?
For that matter, where did *you* get *this* idea? Have you benchmarked?
Further, exactly what do you mean? I agree that communication speed may decrease by quite a bit, but that's not directly correlated to *display* speed. Individual pixel operations are slow, Quake shouldn't use the X pipe. That's obvious. It's slightly less obvious that this is a significant problem for other programs. Sockets are slightly slower than direct memory copy, but unless the video card is *really* fast I suspect the time spent servicing a request far exceeds the time spent in the request. (I haven't benchmarked this either)
Finally, it is my observation after using it that X is not an 'order of magnitude' slower than other display systems -- at worst, 5-10% is a reasonable estimate.
Do you have a constructive suggestion for improvement or are you just getting a kick out of making snide remarks? Having a well-known email address doesn't mean you can simply make insinuating remarks with no explanation to back them up.
Daniel
Re:X _needs_ a good window manager (Score:1)
Actually, you can do that. You can also hide all windows associated with a program, something incredibly useful that I haven't seen anywhere else. The dock is also pretty cool -- it's similar to the panels. WindowMaker also has Gnome-compliance; in fact I have Gnome panels hanging around on my screen right now
Daniel
Re:X Copy and Paste Model is Dated (Score:1)
I think it would be nice if support for both mechanisms could be added, but that's nontrivial..
Daniel
Re:in answer to the original questions... (Score:1)
GNUstep [gnustep.org] is almost to the point where serious OpenStep porting and debugging can take place. (The text system is in flux right now; when that's over, I think it'll be ready.) This means that people writing new Macintosh applications will have a relatively easy time also targeting Linux; Macintosh software developers are the best in the industry when it comes to building usable, consistent interfaces to high-quality end-user applications. (Hey, I'm allowed a little egotism, aren't I?)
What's my point with all of this? It means that X isn't necessarily as entrenched as you think it is. GNUstep runs on X right now, sure, but it could also be made to run on a sane display subsystem without affecting application-level code. So the situation isn't quite as hopeless as it seems.
My prediction: If there is half as much effort put into Display GhostScript and GNUstep as there is being dumped into XFree86 and GTK and GNOME and Qt and KDE right now, X can be put on life support within two years. And there'll be a resolution-independent, device-independent, network-transparent window system with a sizable base of consistent first-tier end-user applications and a very elegant programming interface to show for it.
Re:in answer to the original questions... (Score:1)
Most of the time in OpenStep application development you don't need to write real PostScript code. If you do need to do drawing, you call functions like PSmoveto() and PSlineto() that send messages to the DPS server. You can also write "pswraps" -- PostScript procedures that get compiled into a chunk of code that you can call from C, which when invoked send the whole chunk to the server at once. (This can improve performance because you reduce the number of round trips/context switches required.)
In Mac OS X, because it uses Quartz rather than Display PostScript, the PSxxx() routines should still be usable but pswraps are going away.
Incidentally, one of the reasons Apple is dumping DPS (besides Adobe's outrageous licensing fees) is to get better performance. They're doing this by making most of Quartz a client-side library that draws directly to the screen (or the backing store). They say they're leaving hooks in so remote display can be added back later; of course, some people are freaking out about that, but IMHO Apple has their head on straight. Optimize the common case, make the uncommon case possible.
Re:in answer to the original questions... (Score:1)
X? A standard? What planet do you live on?
There are two standard graphical interfaces in the personal computer industry. The Macintosh interface is the one every other interface tries to be, and the Windows interface is the one most people use. X isn't even on the radar.
(And yes I know there are people who will insist that it isn't X that's the interface, it's KDE, or GNOME, or CDE, or some other crap. They can bite me. X refers to the whole ball of wax now, no way around it, no matter how much semantic BS you try to invoke.)
Re:Berlin Portablity (Score:1)
The last time I mentioned something about Berlin and its strong linux ties, I was told that all the commercial Unicies are gonna fall by the wayside and only Linux mattered.
X technical weaknesses (Score:1)
- Over-reliance on bitmaps.
- Context switch on all drawing apps.
- Lousy color handling. IMHO X's replacement should ONLY support 24bit color. Let the server decide how to draw 24bit colors on a 256-color display, not the app. This might cause problems with graphical programs, but would be a better interface for the vast majority of apps.
- Primitives are too low level. Higher level primitives allow the X server more optimization opportunities with fast video cards.
- Wonderfull usefull cruft that is no longer used, like the stuff that supports resedit.
- <FLAMEBAIT>No sound support!</FLAMEBAIT>
That should do it for me...This is the root cause of the no-anti-aliased fonts problem. Since a lot of the primitive Server-side objects are bitmaps, including fonts, they can't be extended once better ideas come along.
Since you have to tell the X-server what to do even in the local case any drawing requires a context switch. Not doing things synchronously helps, but the answer is that the Xlibs should be able to do some of the drawing directly. I believe that this is a partial goal of XFree86-4.0, but I'm not sure.
Seriously, that's not an X issue but a clean networked sound standard would be a good thing. Especially one that allows dynamic mixing.
Doug
Re:fvwm kicks NT butt! (Score:1)
The NT interface is great for its emetic properties, though.
Re:Is rendering or the transport the issue here? (Score:1)
What in the world do you mean by this?
Genuinely curious,--Q
Beer recipe: free! #Source
Cold pints: $2 #Product
unix haters handbook (Score:1)
UNIXUX: click on the cursor [catalog.com]
The X-Windows Disaster [catalog.com]
What about LBX? (Score:1)
The reason I am asking as I proposed this as a possible bypass to a complex remote Citrix setup at work, but it doesn't seem to be available on the target Sun machine(s) (where the X applications live) - and so I never had a chance to try it out...
--
Re:PM would be a good replacement. (Score:1)
being most notable. Most of the good parts
of PM were very high level, and could be
done by a well-written window manager.
Everything we'd need in a potential replacement (Score:1)
to ssh should be built-in, except modified
so a single channel can transparently
have new applications connected through
without needing to do it via the shell
on the other end. This would eliminate
the need to ssh multiple times. Ideally,
the connection would be handled by a
library instead of a terminal application.
Also, ideally sound would be handled by
the same mechanism.
2) Window Manager agnosticism -- We've all gotten
too used to our favorite window managers
to move to a single one, no matter how
wonderful it might be.
3) Ideally, more of the frontend of applications
would be run on the client, to minimize
communication. This could be accomplished
a number of ways, but a simple way would
be to have multiple application modes, one
of which would tell the client (I'm using
traditional, rather than X notions of
client and server) where widgets are and
only generate events when the mouse is
over the widget. Several other modes for
different kinds of programs would be
needed (consider Xeyes)
3) Automatic dithering and a single color API that
acts like truecolor.
4) A way to nicely disconnect a running
program's GUI from one client and then
resume it elsewhere (to some degree this
relies on #3)
Re:Everything we'd need in a potential replacement (Score:1)
the user is at, and server to mean the other
place
X12! (Score:1)
What an excellent suggestion.. it seems like the best way to get to a better place would be to extend X to X12 and include a more rational color and font system, and to include audio, and retain X11 compatibility for existing apps (an absolute must, really.
No, this won't get rid of X bloat, but it will allow programs written to GTK/QT to have a better substrate to operate on. Of course, high-color displays and the sort of stuff coming in XFree86 4.0 is already going a long way towards a better tomorrow..
Sucky printing not X's fault? Java 2 example.. (Score:1)
No, it's not entirely X's fault, but X doesn't lift a finger to help. Windows and Mac both have a common graphics model for printing and on-screen imaging, and it's silly that X has nothing similar. Yes, you can go up the chain to GTK for this, which is good enough, but it's silly that we've had to wait 12 years to get libraries that will allow on-screen display and printing.
It wouldn't hurt my feelings at all to have a display model based on PostScript or PDF or something sane, but junking X totally is not an option. If we depend on GTK for a high-quality imaging model, though, that means that a lot of the rendering decisions will be made on the wrong side of the client-server pipe. Java 2 does this, and it lets you have a nice and powerful and consistent rendering model cross-platform, but performance on X sucks beans because the X server is basically acting as a dumb framebuffer for pixel-level operations.
That just doesn't cut it. There should be a rich drawing model that can be effectively supported by the rendering server and which can be retargeted in library code to PostScript or any other printer imaging language.
I wouldn't mind seeing Java 2's imaging model made part of a next-generation X protocol, but I don't know whether everyone has enough experience with Java 2 and whether its Graphics2d model has stabilized enough to re-implement it with pixel-precision in C for a graphics system.
If Java2's Graphics2d model was stable enough, and if the ownership terms could be worked out, I'd love to see Java2's model supported on an X type server.. would speed Java code greatly, and would provide a rich and powerful (PostScript-level) imaging model.
X's Color Support Blows Chunks (Score:1)
It's been 5 years since I've done any Xlib/Xt coding, but the biggest problem I remember is that the color model blows chunks on palletized displays.
With Windows, each app indicates what colors it wants, and all graphics operations are done using a handle to the color returned by the graphics system. If another window is in front, the windows rendering layer will automatically dither and/or approximate colors in the background app to maximize color fidelity using the common color map. A similar process is done on the Mac, I believe, with dithering and approximation done for the coder by the graphics layer.
X Windows is different. With X, a program on a palletized display allocates color cells which come straight out of the hardware palette. When a program asks for RGB FFF083, it will get back a simple integer, '5'. From that point on, all rendering done by the program is done using color 5. If the 256 colors are exhausted, the system may try to return color '16' if it is close enough to the requested color, but the system can't change how the program does its rendering behind the scene to give the front window a better color fidelity than the background windows.
This is why Netscape users on 8bit displays are stuck between either running into color starvation extremely rapidly, or forcing the Netscape window to use its own color map, causing horrendous false-color flashing when the window is selected or de-selected.
This problem may thankfully be a thing of the past with modern video cards, but it was always one of the big ugly achilles heels of X. The Athena widget set, font system, and Xt resource complexity were the others, but fortunately we're finally getting away from Xt and all that ilk.
Who *really* decides what's "core X architecture"? (Score:1)
--
Re:X windows woes (Score:1)
I don't suppose you feel like writing a simple app that uses all of the XShape extention features so that I can figure out how to use that one as well, coz that one has me beat entirely, the man pages and xc documentation on them are scanty to say the least,
C.
Re:You've missed the point of X (Score:1)
This D11 [sgi.com] idea is a new one to me until i saw it posted here earlier.
C.
Laptops (Score:1)
MacOS (Score:1)
From an end-user point of view, it's very pretty, and better for most things than Windows 95. Look any deeper and you see its rotten guts.
(I own a Mac and use MacOS, mostly for running various media applications. I've tried programming under it, and after UNIX, it's a pain, even with tools like CodeWarrior.)
NeWS (Score:1)
Of course, back in those dark, unenlightened days, Sun (the owners) either demanded exorbitant licencing fees for the technology or just refused to licence it, thinking that being the only ones with NeWS gave them an advantage. And so, sadly, NeWS died.
The inventors of NeWS went on to create another client/server system, albeit one with a different scope. We know it as Java.
PostScript and NeWS (Score:1)
Re:My Biggest Problems with X (Score:2)
X.Org Becomes X Technology Steward Industry consortium to guide the future of the X Window System
Menlo Park, CA., May 12, 1999 - X.Org, a newly formed organization of The Open Group, has today become the official steward of the X Window System technology and the technical experts for the X Window System standards. Member companies include Compaq Computer Corporation, Hewlett-Packard Company, Hummingbird Communications Ltd., International Business Machines Corporation, SGI, Sun Microsystems Inc. and many others.
--
Re:You've missed the point of X (Score:2)
(I'm curious, what are those non-xterm tools?)
The ability to admin machines remotely is obviously a great feature. But X decided that it was such an important feature that it had to be built into the window system at such a low level that local access pays the price: that is, that it was more important to be able to use the machine down the hall than to be able to use the machine on your desk!
X could have been designed to be efficient locally, with remote access being possible but slow. It wasn't. It was designed in such a way that local and remote access are about equally slow (if you have a fast local network, which was another fundamental assumption of X.)
Wouldn't it be better if remote access was a dog and local access was fast, instead of both being a dog? That's how other window systems do it.
The idea that the way to do network transparency is to have the remote machine be the one tracking the mouse is just crazy. It would be far better for all GUIs to live locally, and for the on-the-wire activity to happen with some more domain-specific RPC, or other services.
(Like, for example, through a web server. CGI is a great example of how to do remote operations while keeping UIs local, and doing it portably as well.)
SGI has a great X server, and it's a credit to them that they made it go as fast as they did (I've never seen a better X server than SGI's.) But it's still ridiculously slow, given what their hardware is capable of! You only have to compare X performance to GL performance to see this.
Re:My Biggest Problems with X (Score:2)
Guess what, Netscape doesn't (and can't) use XCopyArea for scrolling. Because that just moves bits, not subwindows (think form elements.) Netscape plays crazy tricks with window gravity to move all the windows at once, since the alternative (moving each subwindow by hand) is insanely slow.
But probably the reason you see flicker isn't really X's fault, but is because the table redisplay code isn't great.
Re:in answer to the original questions... (Score:2)
I hope you're right; that would be a very good outcome.
It does give me some hope that MacOS X is looking so Unixy, because people who have experience writing Macintosh applications just will not tolerate the kind of UI free-for-all that X brings to the party, so maybe they will actually do something about it.
I don't know about that; I don't think that rescuing all of those NeXTstep applications will really make that big an impact, given how marginal NeXT has always been in the market. It's a nice looking system, no doubt about that, but that doesn't mean it's ever going to catch on.
I'm also somewhat dubious of Display PostScript. I've done a lot of PostScript hacking, and it's frankly a lousy language to program in. (It's a great page-description language, but these days I really believe it's more suited to use as an output format than to use as a language you would actually write code in, and debug.) Of course, I haven't actually hacked on a Display PostScript system, so maybe the DPS APIs are different enough to make it bearable. I don't know. Would someone who has hacked DPS care to comment? Do you end up actually writing PostScript code, or is that hidden behind the scenes somehow?
Re:You've missed the point of X (Score:2)
Well sure -- if what you're doing doesn't require high performance graphics, then the fact that X can't deliver high performance graphics doesn't much matter, right?
It's certainly true that most applications don't require high performance graphics. But when you need it, you need it. And X can't deliver.
Re:X windows woes (Score:2)
This, of course, is The Way of X. Got a problem that people have been suffering from for ten years? Fix it by adding yet another new and optional API! So now all the applications writers get to code their graphics routines twice, with lots of runtime feature-checking. Have you ever written X code that made use of XSHM, the shared-memory extension? Did you do it in such a way that your program actually worked when the extension didn't exist? Are you sure? Did it still work when the extension existed on the server, but the server was on a different machine? Are you sure? (In my experience, 99% of the programs that try get it wrong.)
This is no way to fix a bug. X's refusal to add required features to the protocol (SHAPE is still optional, for pete's sake!) makes life hell for application writers until the end of time. Or leaves users with applications that mostly work most of the time.
window managers (Score:2)
The fact that the window manager is not built into the server really doesn't have much to do with the client/server model. In a Windows-like library world, the window manager could as easily be a pluggable DLL with the same effect, but without taking the X hit of all the context switches and network traffic.
Re:Don Hopkins. (Score:2)
Nice words, coming from someone who's too chicken-shit to attach their name to them. Don's one of the smartest people I know. Who are you and what have you done?
Re:Obsolete colormap problems (Score:2)
Actually, quite a few of the xscreensaver hacks behave very differently on PseudoColor versus TrueColor: the difference will be that, when a colormap is available, the whole screen will be alive with motion, and when there is no colormap, the screen will be pretty much a static image. There are some things you just can't do fast without colormaps.
Another reason for using 8-bit depth is speed: that's 1/4 as many bits that the server has to move around. You might expect that this wouldn't be a big deal, but it turns out that it is. The difference really is perceptible: there are a few hacks in xscreensaver (``compass'' comes to mind) that very obviously run 4x faster in 8-bit mode than in 24-bit mode. Sad but true.
SGI got this right, of course, by having an X server that allows 8-bit-deep colormapped windows and 24-bit-deep non-colormapped windows to exist side by side on the same display. That way, each application can pick the color depth that is most appropriate to its task.
Re:X's Client/Server Model (Score:2)
Ha! Try ``an order of magnitude.'' Where did you get this idea?
WTF? Do you recompile libc every time you compile your program? Are you aware of how libraries work?
Re:You've missed the point of X (Score:2)
I am most certainly not talking about ``dumping the functions that get in the way'' or ``running on the bare metal.'' There's a world of difference between having every application have hardware-specific knowlege; and having every application use proper high-level abstractions, but having the implementation of those abstractions not involve handshaking between multiple processes!
What's this supposed to mean, besides being a dig against the fact that Windows doesn't have memory protection? I think you're confusing memory protection and the client-server model. Neither implies the other.
Maybe you don't realize this, but any X program can scribble on the windows of any other X program. Or even free resources allocated by other programs, causing them to get X errors and (usually) crash. It's not particularly easy to do this by accident, but X does nothing to prevent it (in fact, it's explicitly allowed.) Once you have a connection to the display, you have free reign.
The client-server approach buys you nothing in terms of stability, security, or portability. Those are all orthogonal issues. All the client-server approach buys you is network-transparent graphics.
Likewise, having an implementation that gives you in-process access to the frame buffer (and the ability to do graphics fast) does not imply lack of memory protection. Remember that these clients are still going to be doing their drawing through high-level APIs, and the implementation of those APIs can do whatever bounds checking is appropriate. The X server does such checks internally anyway -- in addition to all the IPC overhead.
Re:X is bad#2: Fonts really, really painful to use (Score:2)
I agree, but...
"-*-courier-bold-o-*-*-*-120-*-*-*-*-iso8859-1"is actually what you should be using, if you want your resources to have a better chance of being portable from one machine to another. That X's font names are verbose doesn't mean you need to specify all those fields.
X doesn't require that level of detail. However, neither does it make the operation you described easy. This is largely because there aren't a set of library routines for doing things like asking for a similarly-sized font in a different face, or the next-larger font size that is displayable and/or looks good.
I'm sure lots of people have rolled their own solutions to this over the years. I did it once in emacs-lisp, and did it again twice for Netscape (which is on its third or fourth version of the font-selection code now, so if you still hate it, it's not my fault any more...)
X's font management is lousy in many ways, but I don't think that its long font names are a problem.
Re:What about Y windows? (Score:2)
SGI uses X, and they have an X server that is insanely optimized for their hardware. On top of that, for anything that actually needs to go fast, they use GL instead of X. Basically, they use X to allocate a rectangle, and then X stays out of the way. The GL library then talks to the hardware directly, without a zillion context-switches in the way.
Re:X's Client/Server Model (Score:2)
I get that idea from having spent ten years trying to squeeze every drop of performance out of X programs as I can. The inefficiencies that the design of the X protocol forces on clients are just staggering! All the handshaking back and forth between the client and server (and associated context switches) adds up really quickly. I see it every day -- I see operations that are fast in every window system that preceeded X slowing X programs to a crawl, and because I know X inside and out, I understand why. It's no mystery to me, it's because of the fundamental design decisions that went into the X protocol on day 1.
I have not done bechmarking, because I have had no reason to. I know X is slow, but I also know I'm stuck with it. However, if you want to try it out for yourself, try and do some simple 2D graphics that do double-buffering using Xlib. Now rewrite that same program using OpenGL (note that we're talking about 2D here, not 3D, no textures. Just line drawings.) Code both programs such that it replaces the image as quickly as it can, yet results in no perceptible flicker. Tell me which one runs faster. Here's a hint: it's the one that can touch the frame buffer in-process, rather than having to suck bits through a straw. (Use the joke of the X Double-Buffer extension if you like, and the XSHM extension. It won't help.)
Obvious, is it? So what you're saying is, ``Quake shouldn't use X.'' Which is to say, ``X is unsuitable for anything graphics-intensive.'' Which is my point.
You're missing the point again. It's not just the fact that there's a pipe involved, it's the fact that there is synchronization between multiple processes: one writes, and flushes, and then some time later the other becomes runnable, and eventually gets around to reading from the pipe, then talking to the hardware, then writing a response, then flushing it, and eventually the first process becomes runnable again and...
When window operations are involved, you often have to block waiting for answers from the window manager, resulting in a three-way cluster-fuck between the client, the server, and the WM. Oh, but isn't it great that they could be running on three different machines? Whatever.
Ah, we've reached that point already I see. We always get here whenever the failings of X, Unix, or anything else Linux weenies hold dear are discussed: the fallacy that, before one has the right to point out a problem, one must have already handed the world the solution on a silver platter. Well guess what, the fact that we're stuck with X forever (because it is completely entrenched) does not mean that X has no problems, or that those problems are not severe. There appear to be some people, like you, who don't understand the extent of those problems, so don't bitch at me for pointing them out, ok?
Bite me, fanboy.
X windows woes (Score:2)
I've also heard a fair number of people complain about X's API and the basic toolkits (Xaw) and how ugly and kludgey they are, but that's what things like qt and gtk are for.
--
rickf@transpect.SPAM-B-GONE.net (remove the SPAM-B-GONE bit)
Hmmm... (Score:2)
If it's possible to have too much of a good thing, though, this is it. X is great for configurability, but it goes too far. Without any sort of "standard" toolkit, window manager, or any such thing, there's no standard sort of interface on which a user can rely. This isn't saying that configurability isn't bad, it's saying that if you're going to make something configurable, you need to set defaults too. X doesn't do that. Consider the multitude of GUI toolkits, three or four drag-and-drop protocols (all of which are incompatible), four desktop environments which don't even share common API's on most things (meaning that support has to be written into an app four times if the author wants to support everyone), and so forth.
X's major weakness, though, is its age. Now, old software isn't necessarily bad. It all depends on how far ahead the developers think. X's original developers thought ahead several years. Problem is, those years ended quite some time ago. Things like drag-and-drop, inter-application messaging, text antialiasing, support for TrueType fonts, and such never made it into X. They've come in since as bolt-on solutions, but these things are so vital to a modern GUI that they really ought to be rolled in (which you can't really do without shelling out obscene amounts of money).
I don't know. XFree 4.0 appears to address some of these concerns. I'll still be giving Berlin a spin when it's usable, though, if only to see if it's a better system.
Re:The X protocol is too slow and chatty (Score:2)
As for remote apps.. X rules in this dept. I find that nothing can come close to X for performance. Things like pcanywhere, carbon copy, etc. have a noticeable lag. (caveat: every win32 Xserver i've tried is slow.. XFree86 on a 486-33/32MB is a magnitude faster than X on win32 on a P11-450).
With X however is impossible to tell whether apps are remote or not. Also, X is perfectly feasible over 33.6k modems for simple Xt type apps (xterm, etc), and even complex apps if you use lbxproxy.
I once ran Netscape 3.0 from a computer in scotland over the internet displayed to my computer in ireland (connected via 33.6k). Took a heck of a long time to draw (~5min), but from then on it was useable (with a little patience). And that was just plain X. I didn't even compress it with lbxproxy or ssh! Try that with anything else and you will not get anywhere.
As for those who argue that "X needs this, and needs that, And that the fact that they weren't included means it must have beem badly designed": The intention was to provide a basic protocol, which could be easily extended, so it's meant to be like that by design.. want Direct rendering? -> extension. Owant penGL?->extension, DPS.. etc.. by design.
I thought before talking: (Score:2)
On the other hand, there are a lot of old laptops out there that aren't upgradable, at least not in the video chipset. If you can upgrade the system RAM (or have enough to begin with), running two X servers at once in different bit depths is a useful workaround. Depending on how you work, that may be less or more convenient than flipping desktop settings back and forth.
Obsolete colormap problems (Score:2)
But is it really such a big inconvenience in this day and age to be unable to change color depths on the fly? Being able to go from 800x600x32 to 1152x768x8 (or whatever; I haven't done the math) might have been important when trying to balance out resolution vs. color depth on a 2MB video card... but every video card in every new computer or store shelf today will do 16 million colors in any resolution you please, and there's just no reason to use a non 32-bit color depth. There's that one xscreensaver hack that uses palette shifting on 8-bit displays and is slow on other color depths... but that's the only advantage to 8bit color left, and there is no advantage to 16 bit color.
It costs $15 now to get a 4MB video card; $30 to get an 8MB card. Bring sandwiches to work for a week instead of buying lunch, and never worry about sub-par color again.
X: To Be or Not to Be (Score:2)
X tends to suffer from what I call "Win32APItis", a huge assortment of functions of dubious utility (it would be "GTKitis" if it weren't documented). Other projects, such as Berlin, seem to have learned this lesson -- it's possible to make an entire windowing system with the simplicity of a "regular" toolkit. Any step in the direction of a less stressful API is therefore a step towards unification of look-and-feel, since developers won't be compelled to write entirely new toolkits to scratch the itch of hating Xt/Xlib
While some of the various extensions that X is now sporting (patches for TrueType support, GLX, and printing) are useful accessories, ultimately they reveal X's age. A lot of the features a modern GUI designer would like simply aren't that easy (or sometimes possible) to implement.
All this isn't to say that we just need to chuck X in the garbage can and start supporting Berlin/GGI/whatever; I would prefer to see a thin (hah) Xlib wrapper on top of such projects, in parallel to ports of GDK or Qt or whatever people like. X has some very strong advantages, which should not be overlooked.
This is why X must die (Score:2)
PID USER PRI NI SIZE RSS SHARE STAT LIB %CPU %MEM TIME COMMAND
391 root 12 0 38356 35M 2576 S 0 1.5 57.0 18:11 X
That's 38 megs, 35 in core.
I now await the standard blather about how "RAM is cheap" and how that justifies this astonishing bloat.
General Overview (Score:2)
Alternatives
There is the GGI-Project, the Berlin consortium and Y. GGI is an abstraction layer for grafics programming, but relatively low-level (e.g.games). It serves as driver lib, can be partially controlled by the kernel (KGI) and can output to different "targets" like svga or X. It also serves as the basis for Berlin, a new windowing system using OpenGL, among other things. Don't know about Y.
Hope that helps a bit
Avus
Why? (Score:2)
There are also control issues. How do I deal with these windows? Do you seriously want to have to do FPS-style moving around to move to a different app? Frankly, this would just be confusing. Please eleaborate as to where this would be useful.
X Alternatives (Score:2)
There are two X alternatives that I can think of besides the Berlin mentioned. One of them is The Y Window System [hungry.com], by the Hungry Programmers (specifically Christoph Toshok), which isn't very far along and as far as I can tell hasn't been worked on in a while (since about February 1998). It promotes the use of a single fixed depth, which I think is a bad idea. It does have some good ideas though, like a somewhat separate memory architecture. Download here [hungry.com].
The other one, NanoGUI [linuxhacker.org], was originally developed by Alan Cox. It was designed with a lightweight memory footprint in mind. I'm not sure if it supports networked display, though, but I believe they're going to at least port VNC. It's being used on the new Linux7k project [calcaria.net], which is attempting to create a usable Linux system for the Psion 5 series palmtop (it uses an ARM7 [linux.org] processor). It seems to be undergoing active development. Download here [linuxhacker.org].
So I hope that's a good starting point.
You've missed the point of X (Score:2)
1) There is no excuse for this one
2) See #1
3) Not true. There IS a lot of backwards compatibility because it DOES get used. X is not all that bloated, although a diet would improve things.
4) If you want a speedier environment (#6) then this wouldn't help. Coding GUI's isn't hard in C, it's merely a matter of preference, and I'm sure many people will fight to the death to keep coding gui's in C.
5) Standardization is a Bad Thing. The whole idea of X is to make something that interfaces witht the video drivers and provides only the very basic tools. Standardization of GUI's is beyond the scope of it. Use KDE or GNOME, this is what they're made for.
6)Your card probably isn't supported very well. There are a variety of reasons for this. Netscape never flickers grey for me.. and my PC isn't exceptional, nor is my video card. Netscpae is a bad example anyways, since it isn't exactly a high-performance piece of software.
7) This is where the windowmanager comes in. And the graphics toolkits. You can't blame X for the variety out there, and X shouldn't make one standard at the cost of hurting the others. GTK+ is making a bid these days for the default toolkit, and things like GNOME and KDE do somethign similar.
Besides the X-consortium thing, your arguments miss the point.
Probably the biggest complaint most people have is the client-server architecture, but there are benefits to this as well (in computer labs, etc..)
which IMHO far outweigh any problems.
Besides, it's not like opening a connection to your own computer is slow, and I remember hearing if X knows its working on the same computer it makes optimizations (but I am not sure on that.)
Which dosen't mean the berlin project is bad. That's the spirit of open source operating systems like BSD and Linux, if you don't like what's out, write your own!
- Paradox
Man of the C!!!
perl -e "print join q( ), split(q.z.
My problem with X (Score:2)
Using X, the mouse seems just a tiny bit less smooth and responsive than running windows on the same machine. Responsiveness to a click lags a little bit behind other systems, and for some reason a click does not always register. And yes, my video card IS supported, and my processor is a Pentium 350, my bus runs at 100mhz and I have 96MB of sdram, so I don't think the computer is the problem.
The speed things are actually drawn at is usually way better than windows or mac, but responsiveness to the mouse and sometimes the keyboard is usually way worse. If X would just start feeling as smooth and responsive as other GUIs, I would be very happy with it, but right now it is frustrating.
Re:My problem with X (Score:2)
I think the best way to describe my experience with X is to compare it to that of using a cheap, POS mouse with a light, slipping ball bearing and defective buttons. Using windows, with the same mouse, feels like using an expensive, heavy mouse with a grippy ball and pad and precise, weighted buttons. I dunno, maybe it's just my computer.
Re:My Biggest Problems with X (Score:2)
Antialiasing in action (Score:2)
For local performance, what about D11? (Score:2)
http://reality.sgi.com/opengl/d11/d11.html
there is a really good article about how to extend X11 with the special case of 'local host' and that would improve the performance that I find could be made better. And that would definitely be good if it is to be used for games and such.
All other stuff about easier configuration, prettier window managers and such is already being worked on and will get better and better. If you can't wait for it you could donate money to people doing it for you unless you can yourself
The Advatages (Score:2)
1) Network support. The ability to start a remote X session is a HUGE advantage. It allows you to run machines without monitirs, it allows you to work in a GUI when you want to do remote administration, etc.
2) Client Server Architecture. This means that we can have any number of Window Managers and switch among them at will. This is great becasue different people work differetly. What is efficient to you is ineficient to me, etc.
While it's true that X is aging, something BIG would have to be developed to replace it (not an impossible task, just difficult).
The truth of the matter is that XFree 4.0 will offer some very modern additions to X's capabilities. Integrated 3D (GLX) support for direct hardware access for rendering, true multi-headed support, etc. The rewrite for 4.0 is also making a lot of 'under-the-hood' changes. They are making X modular (much like the Linux kernel), this means that generally X will be stabler because it will have more common code that will not have to be recreated across a bunch of different servers.
I like X. It could probably be better (what couldn't), but I think it's probably the best GUI system that I've ever come across in terms of flexability and user choices. X 4.0 will bring out many features that will modernize it greatly.
Re:You've missed the point of X (Score:3)
In a word, wrong.
X is slow because of the separation of servers and clients, i.e., the client-server model, i.e., its network capacity. It doesn't matter that it uses shared segments in the degenerate case -- it still takes a dozen context-switches amongst three different processes before an X client can even pick its nose.
Windows and other window systems are way faster because when a program wants to draw a line, the DrawLine call in the graphics library ends up putting bits in a frame buffer. On X, the amount of overhead for every operation is just staggering. Even more so when window operations are involved rather than simple graphics operations.
For the dubious feature of sometimes being able to have clients and servers on different machines, you pay the price of never being able to have decent performance in the common one-machine case.
in answer to the original questions... (Score:3)
There has been a lot of discussion here already about what X's failings are. Quite a lot of it has been wrong (X has many problems, but it's not that ``tvtwm sucks.'' That has nothing to do with X.)
The X chapter [catalog.com] of the Unix Haters' Handbook [catalog.com] really does do a great job of covering the major points. Yes, this was written several years ago, and not all of it is relevant any more (for example, most Linux users don't use Motif, so all the abuse piled on the Motif implementation probably isn't relevant to most of you; and GTK doesn't even use the X resource manager, so most of you probably don't use your .Xdefaults file any more.) But where he talks about the X protocol, the low-level X API, and the horrors that X's fundamental design decisions have inflicted on us (``run xterm well'' with window management added as an afterthought) it's spot-on. The ``Myth: X Demonstrates the Power of Client/Server Computing'' and ``Myth: X is Device Independent'' section are especially key.
But none of that matters . Why? Because it doesn't matter how much X sucks, because X is entrenched. It works badly, but it works well enough. It is the de-facto sub-standard. It cannot be replaced, or even fixed, without rewriting every single graphical application you have ever seen, and that's just not practical.
Worse is Better [jwz.org].
Another point I feel the need to make is that most of the people who have been posting to this thread don't understand what X actually is. Some people are talking about X, and some people are talking about ``the sum total of the graphical Unix experience'', of which X is only a small part. In particular, if you're flaming the way your window manager works, you're not talking about X, you're talking about some random crummy application. There are a ton of window managers (there are possibly even more WMs than there are IRC clients, and that's pretty impressive.)
The source of this confusion is that most other window systems come with policy: the look of the window management controls are built in to the window system itself, as are all kinds of other things like cut-and-paste and drag-and-drop: in the interest of ``flexibility,'' X left all of these things undefined, meaning there is no consistency at all.
X itself is very low-level, handling graphics operations and little else. Though small, it imposes serious performance restrictions by the nature of its design.
Because X itself does close to nothing, on top of it, many organizations have built the so-called ``toolkits'' that let you actually build user interfaces. These toolkits impose policy, and implement all the things that one would expect from a window system if one's first experience with a window system was something other than X.
These toolkits inherit all the limitations of X, and then add more of their own: Athena is ugly as sin, and does very little (it doesn't even have real menubars.) Motif was insanely buggy for years, and is still incredibly inefficient. GTK is slow, and isn't really finished yet. KDE requires C++. And so on. And of course all of them are incompatible with each other to various degrees.
If you're bitching about things not being ``object oriented'' enough, then you're bitching about a toolkit, not about X. X itself is so low level that there's just no need for OO hair: those abstractions come at a higher level.
Some people think it's a great thing that X doesn't come with policy. I say nonsense: rampant customizability is almost always an excuse for not having taken the time to get it right in the first place. I just want an appliance that works, I don't want to have to spend days tweaking it before I can turn it on.
Here's what X's lauded ``flexibility'' has given me: right now I'm looking at a screen that has applications on it written using five different toolkits. They all work basically the same (which is to say, they all work basically like a Xerox Alto), but each one renders menus differently, and half of them do cut-and-paste in incompatible ways. Thanks to the flexibility of X, there is no consistency. I really don't care what menus look like, or how cut-and-paste works; I just wish it was possible to pick one and stick with it.
The other efforts to provide consistency across the desktop (Gnome, KDE, whatever) all start off with the requirement of rewriting every single application to do so! What a colossal waste of time! But there is simply no other way, thanks to the legacy of X: thanks to X's refusal to dictate policy, there is no one policy to replace, there are dozens.
configuration mostly (Score:3)
running. The X server idea with the server
running close to the client is highly useful,
as well as removing the window manager from
the server (as opposed to the options on most
prevalent systems).
Configuration does seem to be the problem
area with X -- especially now that XFree86
has become so popular. Our local NLUG just
had an hour-long lecture devoted to X
configuration (and many of the listeners were
the Linux Literate).
If X could be made to be more readily
configurable (which is not an X issue per se...)
by better configuration tools than currently
exist -- hell, even fetching specs from
www.xfree86.org automatically given a known
card name/chipset would dramatically ease
installation in most cases (most users don't
know where to look and most tools guess horribly
wrong about what numbers go with what cards) --
then X would be more usable by more people.
Another issue is security. Most X installations
are grossly insecure. A secure X distribution
(one that installs more securely by default)
would be a nice touch.
I don't, however, see any competing protocol which
offers anywhere near the utility of X.
My Biggest Problems with X (Score:4)
2) The X consortium maintains full control over X itself... meaning they can (and have at least once) change the licensing to kill off any free implementations such as xfree86.
3) The software is extremely dated with over a decade of backwards compatibility which no one even uses any more bloating the code base.
4) C... Object Oriented environment.. please. I'm sure a lot of people will bash this, but writing GUI programs in an OO language is simply easier. And before you start on the OO toolkits out there, read the next point.
5) Of course there are C++ and Java toolkits out there, but until they are standard within X, it's a big war. I have roughly 15 X toolkits on my machine to run a total of 8 programs and a window manager. Doesn't anyone else think this is silly?
6) Sluggish. I have AccelX and I have to admit the entire experience is still very slow. Netscape flickers gray every time I scroll up and down, windows take ages to redraw when switching between them, etc. I multiboot to Windows and don't have any of these problems, everything is quite snappy... even if it crashes every 8 hours
7) Inconsistant. With all the toolkits out there, it is so very hard to get a nice consistant desktop. I wouldn't even claim that Windows is consistant, but it is pretty close. MacOS is better.. but at least both environments are intuitive.
Once you understand the basics, you can switch between different applications and automatically pickup that the scisors in the toolbar means cut or that the file menu will have an 'exit' entry or even that ctrl-c will copy the selected text (most of the time at least
Of course, I am biased on this subject...
--
Berlin (Score:5)
Berlin operates on the object level. All GUI components (widgets), applications, and non-visual components such as audio components, are CORBA accessible components. This means they are network transparent, platform independent, and language independent.
To do things like displaying an application run on a server on your local workstation (the way X does), we abstracted 2D and 3D APIs as much as possible, we also implemented commonly used functions in the display server to reduce the network traffic as much as possible.
If you are familiar with how ActiveX components in Windows work, this should be a very familiar model. All communication between components, applications and Berlin is done via CORBA using the OmniORB2 CORBA ORB (which is recognized as the fastest CORBA implementation out there).
Because we use CORBA, any language with CORBA bindings will be usable for writing Berlin applications and components. These include C, C++, Perl, Java, Python and much more.
We adopted a paradigm similar to the classic Model-View-Controller so that the look of individual components such as buttons is not directly tied to it's interface and can be swapped out easily and painlessly. New components that ship with applications, and indeed the applications themselves, can be used freely by other applications extending the reusability of code to the extreme.
A lot of Berlin's design was taken from Fresco, the competing toolkit to Motif. Fresco is still one of the most advanced toolkits out there and it's influences can be seen in several newer toolkits such as Java's JFC.
Instead of implementing our own video drivers in userspace as X does, our backend currently uses Mesa an OpenGL implementation, but can be replaced without much work. Current versions of Mesa can use a wide variety of video drivers from the integrated drivers in the Linux kernel to X itself.
Overall, we hope to provide all the power we can to developers while ending the excessive desire to create new toolkits in order to add a single widget or modify an existing one.
--