Slashdot Mirror
picoGUI: An X Alternative?
bockman writes "While started as a PDA-oriented project, the picoGUI people seem to be implementing many ideas which I think would be good also for a desktop graphics server ( high-level client/server protocol, presentation layer in the server _but_ modular, application management also modular,...). So I wonder: what would it take (apart porting tons of applications) to make it a suitable alternative to X+[your toolkit of choice]+[your window manager of choice]?"
pico == 1e-12. So if your average GUI takes 1 GB, this one should take 1/1000 byte.
Without having used it, the screenshots are pretty impressive -- especially for such a young project (compared to X). Personally, I *HATE* X.
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?
So I wonder: what would it take (apart porting tons of applications) to make it a suitable alternative to X+[your toolkit of choice]+[your window manager of choice]?
It would take a reason to replace X. Sure, there's plenty of papers on how X is atrocious and should be scrapped, but it's a protocol that works well. It's been in use for many years and most implementations are pretty fast. In all my years, I still haven't come across a reason to move away from it. If an alternative comes along that offers something X doesn't, then I'd consider it, but it doesn't look like that will be anytime soon. X meets all my needs.
Is your browser retarded?
Before one embarks on such a nobel product, he or she must be prepared for X conquest. Otherwise, he or she will end up like the dozens of alternative-to-X windowing systems littered strung out across the Internet. Don't be a another casuality of X-crazy fanatics; X can be replaced, but only by time.
"The lesson to be learned is not to take the comments on slashdot too literally." --Vinnie Falco, BearShare
Well, actually, it seems that almost all desktop apps for Linux are written using GTK or Qt. Although PicoGUI is supposed to provide its own widgets and such, a Qt/PicoGUI and GTK/PicoGUI would ease the transition and make a lot of apps available under PicoGUI.
We have Berlin after all. =P
Don't think of it as a flame---it's more like an argument that does 3d6 fire damage
The one thing I'd like to see is a set standard GUI services on top of the core drawing engine. Different widget toolkits would be a thin wrapper on top of these standard services, and different widget toolkits would exist to customize the standard services to each language and development model. This way developers could code to whatever API they enjoy (Qt'ish, GTK+'ish, etc) but since these APIs would map to a common set of services, applications would interoperate perfectly. In fact, with would then be easier to write wrappers for "legacy" apps that use straight GTK+ or Qt.
A deep unwavering belief is a sure sign you're missing something...
It is so sad that many in the linux community are so obsessed with "eye candy" and the latest experimental GUI. The flexiblility of LINUX when it comes to the GUI gives it enough rope to shoot itself in the head with. I know the reason why most of my friends work with MS windows and the Mac OS... there is a uniform user interface that works (flaws and all) fairly well. I don't have to sit there and think... gee do I have widget set X with static libraries Y and did I make the right offerings to the gods of LINUX... you get the picture. So picoGUI looks cool... who gives a sh.... (of course this will be modded as flaimbait... since I don't slobber at every would be GUI posted on slashdot)
Take a look at the screenshots. There are no xeyes running! How can we take any X alternative seriously when they don't bother to port xeyes.
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"
That's just a theme, you idiot. I'd like to see you do better.
If you provide the X-windows service, then you are an X-server, whether you call yourself one or not. So I'm not sure what it would mean to emulate X. If you somehow support X plus some other features, then that would be more like extending X than emulating it.
Personally I don't have any problem with X. I like it. Most of the sensible complaints I hear about it seem to be coming from people who want features that aren't there yet, or who feel the performance isn't up to snuff. These are almost drowned out by people who don't really seem to understand what X does.
I mean, X is a fairly generic display system, as witnessed by the fact that blackbox, matchbox, twm, fvwm, enlightenment, etc, which all look very different, are all just X clients.
Anyway, it might be possible to address the features issue and still have emulation, but I don't think that performance issues will be solved by emulation. And, when you look at all the graphical programs that use X, it seems kind of hopeless to expect that X will go away and be replaced by something else.
Although, if you could port, say, motif and gtk to some new, non-X system, then you could probably leverage a lot of other stuff over to that system relatively quickly.
MM
--
By including this sig, the copyright holders of this work or collection unreservedly place it in the public domain.
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 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?!]
---
the pen is mightier than the sword, the sword is mightier than the court, the court is mightier than the pen.
Is the issue that XWindows isn't as fast as it could be, or that the implementation you are using isn't as fast as it could be? I'm not looking to get flamed here, nor am I pushing one product over another. However I did recently try a commercial X product on my Linux machine and the difference between it and the default server shipped with Mandrake (not mentioning names on purpose here) was tremendous. The commercial product, while not cheap, was noticably faster and "prettier" than the default one.
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.
What would be the point in replacing X? It works. It is functional and does everything I need it to. but most of all, it is UBIQUITOUS. You would need a very good reason to have everyone switch away from what they use. (for example, even though Linux is obvioiusly better than Windows, Windows still rules the world).
i think it goes without saying (except here) that the main reason for a linux user to ever have a GUI these days is web browsing.. port Mozilla!
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
-73, de n1ywb
www.n1ywb.com
Eventually X will be able to change resolutions - it just a matter of time. There are some ways to do it even now without shutting down.
Have you tried using dga modes?
There are some other problems, however, that won't go away ever...
Mod me down and I will become more powerful than you can possibly imagine!
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.
I like what I see (I don't care if it's a blatant rip of OSX, it looks good either way.)
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.
X is a well-designed system which serves everyone's needs, works now, and is compatible across the UNIX world. It would take a lot to displace it.
More to the point, in discussions like this everyone always says... "of course it would have to be backward compatible with X..." But these people fail to understand that the only way to be backward compatible with X is to implement the X protocol stream. And once you do that, ta-da you're an X server once again, just like XFree86.
Of course, if your lovely new GUI doesn't reimplement the X protocol and the client/server model, you render useless decades of program code, from ancient embedded applications all the way to current UNIX ports of OpenOffice and Mozilla, from astronomical observatories to cash registers.
And of course, then you will lose one of the biggest benefits of X: the X protocol stream and the client/server model. D'oh!
X is not going away.
STOP . AMERICA . NOW
Some compelling reasons for me to use a new GUI server/api would be: 1) Easy to use, highly accessible interface. Something easily accessible to Java devs and (don't shoot me) Web Service developers. 2) Emphasis on vector/3d/procedural graphics vs. raster/bitmap graphics. 3) Something with a more context-aware paradigm (desktops and start menus are becoming too monolithic... how about some logical use-based partitioning). 4) Strong emphasis on platform independence. I'd really like to see a better (mainstream) alternative to Web GUIs for multiplatform UI development.
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.
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.
-- 2 + 2 = 5, for very large values of 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...
Sticking feathers up your butt does not make you a chicken - Tyler Durden
many of problems brought up by many comments above are of the sort "for desktop gui use, X is bad." they like the screenshots of picogui? it seems to offer transparency. that is all nice, but does transparency REALLY add any functionality? not really, just eye candy. X was meant to be a generalization of all possible usage scenarios. it DOES sacrifice blazing speed for network transparency, etc. any toolkit that is better in any one thing would need to be worse in another. and it isn't, it will probably be JUST as slow.
BSD is for people who love UNIX. Linux is for those who hate Microsoft.
Basically, everything depends on X, so you can't really replace X and maintain backwards compatibility. In order to have backwards compatibility, you would need to provide all the services provided by X, so you would, in effect, just be writing a new X server.
If you really want to replace X with some other system, then you could probably get pretty far by just porting gtk and motif over to the new system. This should pick up quite a few apps. I have no idea how hard this would be.
But, by and large, it's silly to constantly rant and rave about X. It's just an abstraction for a video driver that allows you to effortlessly traverse networks. It is so low level, that it almost doesn't make sense to criticize it. And I think many of the critics don't really understand fully what X is.
For example, if you don't like the performance, then that is a complaint against the specific Xserver you are running, not against X itself.
If you don't like the widgets you are using, then that is a complaint against the widget set you are using (motif, gtk, qt, etc.). This has nothing to do with X.
As far as features go, if you really want a feature and X does not provide it, then you have a legitimate complaint. But really, what more do you want from a video (and mouse and keyboard) driver than the ability to get information about GUI events and to paint the screen in any fashion you desire?
To sum up, I don't see that X is inherently problematic. I think that most complaints about it are misplaced, and should be directed elsewhere.
Furthermore, when people talk about replacing X, they seldom seem to appreciate the benefits of allowing the application to connect to the server over the network. This is one of X's strongest points, yet most people seem to want to replace it with what ammounts to a widget set rolled up with a local machine only video driver.
Well, that's my $0.02.
MM
--
By including this sig, the copyright holders of this work or collection unreservedly place it in the public domain.
viGUI? emacsGUI?
http://www.club977.com/ - The 80's Channel!
Your source for commercial free 80's music!
Check out the screen shots for more.
Some information for the curious:
- Micah (the lead developer) compiled some info at http://picogui.org/wiki/view/Main/PicoGUI and http://picogui.org/wiki/view/Main/FAQ
- 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 alternativesI say ride it until it starts to get modded down -1 Troll. ;)
Their mission seems to be to write a very lightweight window manager. If you don't like the theme, why don't you contribute to the project?
Well, I don't want to join the legion of lame, rabid, my-linux-right-or-wrong, flamers, but, well, your comment shows your ignorance about X, and I can't let it pass.
X is, conceptually, little more than a video driver that can work over the network. The fact that you mention X in the same breath (if you will) as gnome and KDE shows me that you don't really get what X is. Hopefully you do now.
As for the rest, I will take your word for it. I have no experience to the contrary.
Personally, I don't ask much of a window manager, and I don't have a desktop, so I am quite happy running gnome (using the enlightenment rip-off theme) and no nautilus.
I used to use enlightenment plus the graphical midnight commander, and that was almost perfect for me. One day I decided to try gnome, and now I'm too lazy to switch back. I did prefer enlightenment, though.
I would say, however, that if you don't like linux, you should continue to complain about the bits that give you trouble and ignore all the flamers. Some companies pay lots of money to find out what consumers think of their products. You are providing honest feedback for free.
MM
--
By including this sig, the copyright holders of this work or collection unreservedly place it in the public domain.
... from Apple for blatantly ripping off the Aqua GUI?
;)
Come on guys, lickable buttons and pin stripes are so last year
Say what you will about Windows but at least it's a standard to work against. With Linux it seems there always some pertpetual tinkering...enough already! Enough tool building, now make some apps.
Look how many freeware and shareware files are available for Windows. Sure, they're not open source but a lot of people are still writing apps for Windows. For example, go to hotfiles.com and search for "word processor". Quite a few choices. For Linux, you've got...AbiWord, Maxwell, WordPerfect, StarOffice/OpenOffice.
The point of all this is that most people don't care what's the newest/greatest/most different way of doing something. They just want something that turns on and works. So don't think about replacing X, think about making more applications for the end user.
You may be right about the benefits of having a consistent look-and-feel.
;-)
But this has nothing to do with X. X is a low-level, display server technology. It has nothing to do with look-and-feel.
There is no reason related to X itself that we cannot have a consistent look and feel. All it would take is a concensus on the part of new developers. Also, if people are interested, they can always update some old classics (such as xv and gv) to use new widget sets. I have no idea how hard this would be, but I'm pretty sure it is too hard for me to take it on.
MM
--
By including this sig, the copyright holders of this work or collection unreservedly place it in the public domain.
It's called XRender + a couple related extensions. So far they're XFree86-specific, but probably not forever.
DNA just wants to be free...
The 8 years it took for X to get the RnR extension is an example of why so many say "X is Bad". If the extensibility is so great, then why did such an obvious improvement take so long?
(Counting from when Microsoft first introduced that feature, and including the fact that end-user desktops don't have RnR yet)
Blame the clunkiness of the linux desktop on the linux desktop, not on X (in general) or Xfree86 in particular.
There are a lot of concepts associated with X on linux. X, in the form of Xfree86, is at the bottom. Then on top of that there is a widget toolkit (i.e., gtk+ or athena or motif).
Interacting with X is the window manager, which may use a widget toolkit, and which excercises control over placement, size and other characteristics of application windows. Each of these application windows gets to decide how the pixels it has control over should look, within the limitations of the display device. And, in many cases, these applications are built on top of a widget toolkit which may or may not be the same as the one used for the window manager. Then there is the "desktop" which is really just another application.
So, you see, "X" is probably not the cause of the clunkiness you perceive.
On the other hand, if Xfree86 is genuinely too slow, then you should build (or clamor for the building of) a faster x-server.
But don't throw out the whole concept of the x-server, for it gives us many benefits, perhaps most importantly, network transparency.
And, by the way, most people are not saying "Why change? X is ubiquitous!" They are either saying, "it will never happen: X is ubiquitous" or they are saying "Don't change it, because there isn't a superior alternative yet."
I, on the other hand, am saying "don't blame X for problems which lie elsewhere." And, perhaps, "don't put forth an opinion on X if you don't really know what it is."
Oh, and, "the PicoAPI has something like 70 functions in it. Let's not get carried away!"
MM
--
By including this sig, the copyright holders of this work or collection unreservedly place it in the public domain.
Wow, PicoGUI is pretty impressive.
For a different approach to this problem, check out the XML Windowing Toolkit; its "display server" runs as a Java Applet, or ActiveX control, so there's nothing to download/install. There's also a native Linux client.
The basic concept of X is sound, mature and very farsighted. We have some implementation work to do, but we also need to remember to keep that seperate from the actual value that X provides.
:)
Most people here like UNIX right? You can package all of those X complaints up and apply them to UNIX in general. When you do, Guess what? They are the same arguments. All of the things that make UNIX like systems, such as Linux, a good thing are the same things that drive some people nuts about X.
The reality is that using a *real* computing platform requires a little learning. In the last 4 years, the rate of improvement is astounding really. One or two more years and it is going to be solid.
X is a part of that work and brings with it some serious benefit. Again, I ask: "Why trash all of that, just so we can start all over again with a simpler and more limited system?"
It is not worth it.
There is a trade off between easy to use, and capable. You can also factor in common knowledge to understand how this applies to X today. Lets call this the "happy point".
Right now, there are a lot of people who got started not knowing what network transparent display systems actually mean. This is because the platforms they worked on did not have them.
So common knowledge is low for people coming to Linux right now. So the "happy point" is way toward the ease of use side of things. Makes sense really, because you don't miss what you don't yet understand.
Over the next couple of years a few things are going to happen that will essentially make this point moot.
X configurators will get done for most people. Most of the hard stuff will be abstracted into a few sensible combinations that people need and they will work. Progress so far shows me this will happen.
Some of the brighter ones will start understanding just what X is giving them and will start liking it. Articles, reviews and product feature checklists will start to mention this point.
Remember X is a serious differentator for UNIX like systems. It allows us to do things that make a lot of sense and provide a lot of value.
X server performance will cease to be an issue. There is simply nothing that prevents X from being as fast or faster than the very best frame buffer systems. Nothing. I have old SGI machines with simply *excellent* X servers. They understood X and made it work to its best advantage. The result: 30 Mhz machines that are just as snappy as the machines of today.
Don't tell me X is inherently slow. For each argument, I can point to the source of the problem and that source will be implementation, not the basic premise of X.
So all of this will help to raise common knowledge. As this goes up, that "happy point" will move over toward the capability side of things.
After a couple of iterations, we will wonder why it was such a hassle. I did when learning and it was harder then. Now it is fairly easy. In a couple of years, the things people want most will be in the GUI, for the rest of us, we can continue to meld X into performing whatever display task we want.
Only well planned scalable software with vision does this sort of thing. UNIX does it, thats why we like it, X does it, and that is why we will like it too.
I am *really* tired of hearing X sucks tirades. Is this bash X weekend or what?
Guess I will have to just post X is good tirades each time. Perhaps the truth lies between
Blogging because I can...
There's no implicit reason that you'd have to choose. At this point, it comes down to developer choice: what do you want to develop on?
X will never be replaced
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.
A good step in the right direction would be:
1) Write a simple X replacement. It doesn't have to have all the fancy trimmings like direct rendering or opengl extensions and stuff immediately, those can come in time. A nice modern graphics hardware abstraction/acceleration layer that's networkable. Another big win would be if you could make it backwards-compatible with Xfree86 4.x's hardware driver module interface, so that you could steal their hardware support temporarily until the new things get enough popularity for people to tailor drivers to it for you.
2) Port gdk/gtk and qt to your replacement. Immediately a whole lot of linux desktop software now works fine.
3) Write an X compat library, possible stealing large amounts of X code in the process. This allows legacy X apps (those not written directly to gtk or qt) to be displayed.
Steps 1 and 3 are of course huge, but I think there's a number of projects in there that have done some work towards this type of goal, it just hasn't all come together yet.
11*43+456^2
But seriously, with the exceptoin of bugs, there arn't any other complaints you can have about any piece of software.
Im not here now... Im out KILLING pepperoni
As many other people have pointed out, X is fine. Problems people have with "X" are really problems with either the implementation of X, or problems with their widget set. People complain X is slow. Now, X isn't slow: you're using a crappy implementation, or crappy drivers. Its not X's fault. Get better drivers, get a better or update implementation. Go to XFree86.org or try out Accelerated X. If you want a certain feature that's not there, its probably your widget set.
In short, before you say X sucks, identify your problems with it, and ask some experts about how to resolve them.
One thing that I will criticize X for, however, is that they don't enforce some kind of standard for interfaces. One thing Linux does need is standardized interfaces and key combinations between applications. There doesn't need to be one standard, but apps installed on a user's computer should all obey the user-defined standards. CTRL-V should always past...it shouldn't be CTRL-V or ALT-V or CTRL-P depending on the app. Same thing with menu's and stuff. Why should every developer have to reinvent the wheel? And why should the user have to reorient himself for basic key combinations for every program?
social sciences can never use experience to verify their statemen
I have to agree, do a "ps aux" and take a gander of whats running when you run gnome.
I'd like to take this opportunity to plug windowmaker here;-)
I'm not trying to put down gnome here, some people love it, hey if it works for you cool.
This is what makes x cool, you run gnome I run wmaker and we can do it on the same machine running the same apps, at the same time if we get trickey and have the horse power.
X runs pretty damn fast on my dual celery 500
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.
This is SO educational! -- Kintaro Oe
If the extensibility is so great, then why did such an obvious improvement take so long?
Because until the late 90's desktop UNIX renaissance brought about by Linux, KDE, and Gnome, people figured there was no point in pushing that particular rock uphill. Would you spend years of your life trying to improve the foundations of X so that CDE could do some fancy new graphical thing?
Please.
Since the founding of the XFree86 foundation, X has been improving at a faster rate than it has in fifteen years. It's still got a ways to go, obviously, but X has proven itself rich enough to be extended without breaking backwards-compatibility.
- jon
Ganymede, a GPL'ed metadirectory for UNIX
I guess I basically agree.
Although, I just use linux because I like all the geeky stuff it can do and for philisophical reasons related to free software.
I don't mind not having a consistent look and feel across apps. I am not a linux evangelist, though. I don't try to convince people that they should switch, and I don't really care if people switch. I just want there to be enough people using it that it continues to be viable.
MM
--
By including this sig, the copyright holders of this work or collection unreservedly place it in the public domain.
lot of people are still writing apps for Windows. For example, go to hotfiles.com and search for "word processor". Quite a few choices. For Linux, you've got...AbiWord, Maxwell, WordPerfect, StarOffice/OpenOffice.
Your link doesn't work for me; apparently it detects I running Linux and gives me the ZDNet Linux download page.
You forgot about Ted, and KWord. More importantly, writing a new word processor is pointless. What you need is one word processor that does everything in everyone's language; in Windows, Word is basically the only word-processor that gets used, with exception of a few historical niches for WordPerfect.
If you read the recent article on why slashdot users use windows, the people complaining about application support were (a) claiming that Gimp (e.g.) wasn't as good as Photoshop, (b) using expensive proprietary programs that have very limited markets, or (c) game players. I don't remember anyone saying they couldn't find a word processor.
Because until the late 90's desktop UNIX renaissance
The late 90's means 1997 or so. It's 2003 now, that's 6 years. And it'll surely be at least another year before RnR becomes broadly available. That's a long time. (Especially when you consider that the RnR guys only needed a few months, once they started. This suggests that writing extensions is so hard that only a select few can do it. Not encouraging)
Apple and Microsoft have both improved their GUIs enormously since 1997. X (and the other Unix graphics system, OpenGl) don't seem to have gotten much better during that time.
Since the founding of the XFree86 foundation, X has been improving at a faster rate than it has in fifteen years
XFree86 was founded in 1994. I guess I don't remember how well X worked in 1979, so I can't comment on how fast it's progressed.
It's called DirectFB. GTK+ apps can already run under it directly. All it would take is to make sure that the pieces of GNOME that relied on something from X as opposed to the GTK+ interfaces are migrated and you'd have it.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
You're the man. That'll do nicely.
I'll be using that when I have to be at Windows machines. Still...its not easy to get some of the less knowledgeable to use something that complicated to install.
Mod me down and I will become more powerful than you can possibly imagine!
I think they always had it.
However, thin client support has only been added to Windows very recently, unlike X, which always had that. It comes from the different origins of the two, of course.
On the other hand, you don't have to restart your machine to restart your X server, but you do have to restart your Windows machine if the Windowing portion goes down, so the difference is noticable.
Heck, with the help of XDM, whenever my X goes down (as a result of me pressing ctrl+alt+bkspc), it comes right back up. I use it to change resolutions all the time.
Mod me down and I will become more powerful than you can possibly imagine!
People like thier existing WMs. Adoption will go much better if it has an identical WM interface so people can use thier WMs without recompilation.
Copyright Violation:"theft, piracy"::Anti-Trust Violation:"thermonuclear price terrorism"<-Overly dramatic language.
We have three computers in our house on three levels (Duron, K6, Laptop). With X, I can log in to any of the computers from any of the other ones and start working just as if I was sitting right in front of it (my wife, who was a Microsoft consumer only before she met me, had a Dickens of a time understanding that concept). I need network transparency.
I also use two desktops, depending on the load my applications are going to put on the machine and if I feel like eye candy (KDE and Blackbox). With Blackbox (for non-Unix people: lightweight, minimal window manager), I can do amazing stuff on my K6 because the GUI is not sucking up all the resources (aka "Morbus microsoft", now also known as "Morbis apple"). I need multiple window managers because of different resource needs.
Now I'm sure you could probably include these in picoGUI, but then all you have done is made a new version of X without the decades of testing that has gone into the real X. Come back when your software has a track record of more than ten years, and I might look at it for a core system: I want proven stability. The last time my X crashed it was because of Nvidia's shitty closed source drivers; since I switched to ATI, it is solid like a rock.
Oh, and what about those old graphics cards I have sitting around here? Are you going to backport every single driver, so I can still use my Oak VGA card with 512 KByte RAM? That might not sound like much, but with X Window and that card and a PI or even a 486, I can still build an X terminal and hook it up to anything. I want maximum hardware support.
No thanks. Enjoy yourselves writing picoGUI, it's a free Internet and and new software is always a good thing, but don't expect to replace X. If it works, don't fix it.
... take a look at ENIÄK. It intends to bring a logically structured framework to GUIs such as HTML is to the Web or LaTeX to publishing; granted, it's been stalling for a long time due to the main developer having other things to do, but the concept is fascinating: imagine no longer needing to think about the concrete graphical layout, widget sets etc. when developing the interface for an application. Imagine just defining it in the sense of determining the logical hierarchy of elements: windows, text entry points, buttons, menus -- anything conceptually different from another element. And forget about the layout: the (yet unproven) goal of the architecture is that just as LaTeX automatically positions your document so that it is as readable and good-looking as possible, ENIÄK would automatically position and render the elements of the UI to create an optimal user interface.
Many other advantages can be derived from the user interface not being defined physically but conceptually:
OK, enough advocation. Problems do still exist with the concept, mainly a) it's not compatible with any existing application and b) there's no proof of concept until a sufficiently advanced display server is created that actually shows some indication of that the server can adequately automate the process of transformation from a logical, structured interface description into an intuitive, user-friendly physical interface. There's a long way to go, but still, I can't help but to be fascinated by such a concept of abstraction. For more info, read the white paper or complete specification
"Make it more low-level and very easy to setup and change the resolution."
XRandR. 'nuff said.
Where in the world have you been all this time??
Since all of these are very much different from X. Some of the projects mentioned go way beyond anything proprietary GUIs can do today! So if we are reinventing wheels, at least we are improving allong the way.
Regards, Tobias
Regards, Tobias
Windows? A standard? So I take it you missed the whole .NET thing (totally revamping win32 development from the ground up), the Longhorn Storage+ project (scrap ntfs, replace with database) etc etc. The very nature of open source is that it's constantly experimenting, trying to find new ways of doing things. If you think only open source does research, then you need to check out the Microsoft UI Research website.
You're right partially, X is here to stay for a long time yet. However, I certainly think what these guys are doing is cool, and I'm happy to see that some people are thinking about what comes after X. I mean, surely you don't think that X is perfection itself do you? That it cannot be improved upon? For now, we're happy with X I agree, it's a fine graphics engine, but maybe in the future people like Micah will give us something better.
I think it would take something amazing to replace the X Window System. There have been a few attempts to replace it. picoGUI appears to be a inspired by QNX's Photon microGUI (hence the blatantly similar name).
I think you hit on the real problem though, standardization. There is no single central Unix vendor than can dictate UI design standards or enforce a single widget toolkit. picoGUI has a snowball's chance in hell of becoming the defacto widget/windowing system. Hence it will just serve to fracture the UI experience even more.
My complaint about the UI on Linux/Unix has always been that it's so frickin inconsistent. Too often apps do things differently. Not better, just differently. Everyone can make their own super neato widget library and it's not that hard to make your own X replacement.
That's the problem. Don't try to invent your own window system, menu ordering or UI interactions, just base them on Windows as much as possible and forget about "the best" way to do things. With KDE (don't know about Gnome, never liked it) that is happening, slowly. Maybe picoGUI is taking the right approach by limiting the ability to make apps with fucked up GUIs just because you can and "Windows sucks", but most Unix diehards will loathe the loss of flexibility.
-Kevin
X has a lot of apps for it... people bitch about the lack ok apps for linux, but X actualy has a supprisingly large number when you think about it.
And I think what the parent was trying to say was would it be possible to rewrite the X client libraries so that they map all of the X11 protocol to whatever protocol picoGUI uses, so there is no emultation in picoGUI anywhere, but X apps can still run through the modified X client libraries
Konqueror runs in Enlightenment just fine thanks.
and iirc Mozilla runs just fine in KDE
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
Everaldo is a pro working in Linux themes and art and is IMHO doing a great job. Crystal was originally written by Everaldo as a custom KDE theme for the Conectiva linux distro, and later published under an open license. Everaldo also made the "big eight" wallpaper for Conectiva (also used by Mandrake 8 and others) and IIRC part of the YaST art for SuSE. His latest artwork is the "steel donut" theming for KDE and YaST in Conectiva's UnitedLinux-based distro.
Instead, fix the current one.
Current wheel ( X ) comes in several colors ( platforms ), the protocol is universal ( remote display too ). X is mature, and has millions of programs written for it NOW.. not SOMEDAY..
It has all the functional components that is needed in a graphic subsystem.
Sure, its *not* perfect, but spend the time enhancing it instead of tossing it out.
Plus people need to learn to sepreate the X subsystem to the GUI on top before they start comparing things... One cant accurately compare wheels to bricks..
---- Booth was a patriot ----
For PDA use, you should consider porting "dillo". It doesn't do frames or javascript, but it can render most other sites and the executable sizes is about 230k.
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.
This is very true. Remember, GTK+ sits on top of a device abstration layer. So, as an example, you have:
Gnome
GTK+
GDK
GDK Abstraction
Xt
X - protocol
That's a lot of layers and overhead there.
I always wondered how worth while it would be for someone to create a replacement or Xt. That is, something that wasn't as low level.
Not only are you wrong on the merits (since X's limitations - which don't bother you - are the death of a thousand cuts to innovation among developers as well as adoption among users), but you are wrong on the principle. Do something for the art of it. For the love of it. Don't refuse to do something new because what's old is "good enough."
Want to Know How to Cheat the GPL? Read On!
People don't seem to understand that PicoGUI is designed completely different.
...) are independently coming to similar design decisions should be a strong hint that they might be on to something.
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.
The reason X is mistaken for GTK is because most normal average computer users don't know the difference. One sees GTK based programmes and window managers such as the GIMP and GNOME and assumes that that IS Linux. Those that use SuSE see KDE and wonder why ALL programmes don't use that (including the GIMP, notwithstanding the fact that GTK comes from the GIMP). The point is that average users don't know or care why the GTK toolkit is so incedibly ugly (for them looks DO matter) or why X is not very flexible or easy to configure. They just give up and either use KDE or go back to Windows or use Mac OSX.
Linux needs one standard windowing protocol and system, either GNOME or KDE, not both. The continual clashing is hurting Linux and making it harder for developers. Time for a change.
But to answer the question:
1. Any "captive" application - think stripped browser on a kiosk - could use Pico.
2. If the TOOLKITS which are (or should be) platform-neutral are ported. Qt is probably a good candidate. The Zaurus already runs QPE and Pico separately, but it isn't much of a leap to do QPE (already over Qt) over PicoGUI.
But before you get too excited, the code is still in an early state, at least as far as compiling on every platform. It keeps client-server though.
And I need to address some other comments about X.
First, it isn't that slow, and one of the problems is that a lot of software is assuming SHM or other extensions that force things to be local.
Second, dxcp or other programs can compress the X stream to make it usable over some slower links and would reduce bandwidth in any case.
Third, if you are doing remote control or something similar, VNC or something similar is the correct solution.
Fourth, X is the basic set of protocols. But in many references they mean X plus every toolkit, extension, and window manager and probably a few applications. Some things are only big because of these accretions.
Citrix, or almost anything else on Windows is a hack since Windows was never designed to work remotely.
You can criticize X all you want, but it is opensource, so you can fix or enhance the problems, and it seems to work well enough to allow the wide adoption.
And PicoGUI addresses one of the major points - the need for a lighter weight system for embedded and small computer use.
X is not perfect, but it is damn good. Everything can be improved on --that's what computing is about right now.
We need to make full use of what we have now though.
Blogging because I can...
You know hard things are hard. Setting up a single display is easy. Networked ones are harder. Multiple displays networked are still harder.
Ease of use always detracts some from capable. If we do a *lot* of work, we all become happy about how capable the system is.
I am not saying we cannot have both.
But a large part of that work is education about the nature of X itself. This directly impacts how easy to use it is.
Just because someone puts a nice interface on something hard, does not mean it is easy to use when the task is not understood.
That is the problem many folks have with X. It is the same problem I had.
Blogging because I can...
You confuse X with things that depend on it like display managers, input device drivers and such.
If you want a desktop GUI that has openGL underneath, that can be done in X.
The old machines I spoke of where SGI machines. They did have accellerated graphics, could display video in a window, use multiple screens, drive a 3D display and do all the other things you mention now.
None of this is a problem with X. In fact, take a look at some of the visualization research going on right now. A lot of people use Linux and X to drive all kinds of things.
You said it all in your last paragraph. We don't need to throw X out, just fill in the gaps a little.
Someday, X will be replaced, but it won't be for a long time.
Blogging because I can...
There's nothing wrong with X. Most of the problems that people have with X don't have anything to do with the stability of X, they have to do with the API/toolkit, environment (KDE or GNOME), and/or the window manager. Those are the entities that "crash" the GUI. The problem is that a lot of newbies and even moderate users are not familiar enough with the system to understand this. They assume that because X disappeared off their screen, that X is to blame. I used to think this way as well, but after having gotten into Linux really in depth and compiled X a few times, I see now that the real culprit are the X clients, not the X server itself. The only thing the X server does that would lead someone to this conclusion is that it usually restarts: (Screen goes black, and X restarts, either resulting in just the X cursor on the checked background, or a DM pops up 'XDM, KDM, GDM, etc...' And, last not not least, if you are starting X with 'startx' (unmanaged), then yes... the GUI just disappears and takes you back to a *sh shell.)
:( ) Of course, the best feature hands down is the network transparency. Running X apps remotely and having them display on a local system is just great and much more flexible than Windows XP RDP. Especially since you can have applications running on several different systems all displaying on the same desktop (not in separate windows like RDP). Combine this with the Low Bandwidth Extensions (lbx) and you can do this over slow links with speeds that are pretty close to RDP. Your local X display becomes the main head for multiple servers this way! How cool is that?
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.
I read (cannot find a link) another day that Gnome eventually will migrate from X to direct frame rendering. And I think that Gnome will manage to save most of existing Gnome applications as they are written with GTK, not X11 code. That's the way of evolution.
Less is more !
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.
Linux bigots have been saying this for how many years now? "Next year, Linux/X/GNOME/KDE will be the ultimate user desktop! Just wait and see." That is so 1995. Sure, the Linux kernel can push bytes over ethernet at world-record speeds. But why can't those same speed freak gooroos do the same with X performance? Because open source only scratches the itches of the people developing it. So the "Happy Point" for new users will never be addressed until someone tries to sell them something for their money..
cpeterso
I don't know how many of you have actually used the Photon microGUI on QNX, but I believe its the way a GUI/windowing system should be designed.
Its simple, its clean, its fast, and it provides a nice network extensibility (using QNet).
Could X be all of that. Yes. But not in its current state. To me, X seems much bigger than it actually needs to be.
I stand behind everything I said. Rather, your high-handed attitude and refusal to answer the points is the very paradigm of condescension - not to mention that it makes it clear you have nowhere to go with your argument.
Want to Know How to Cheat the GPL? Read On!
X really isn't as bad as many make it out to be. X is -NOT- slow -- it's just that KDE and Gnome are bloated. Not only that, but while I don't intend to troll, the interfaces aren't very consistent, even with themselves.
As Guillaume Maillard stated on OSNews, X can be made to be fast.
The man reason I don't like X is because of GUI inconsistencies. Even when Redhat used the same theme on KDE and Gnome, I would still see a lot of inconsistency in applications. I don't have a current Redhat install right now, but if I remember correctly, launching KWrite from Gnome would have "bad-feeling" scrollbars. In short, it's not just the look of the widgets that matter, it's also how they behave. CONSISTENCY IS IPMORTANT as far as I am concerned. (Ironically, I prefer using WindowMaker over KDE and Gnome. The desktop's interface feels faster as a whole, but applications are still as inconsistent as ever.)
So really, the problem is not as much speed as it is consistency. If PicoGUI manages to emulate X, what good will that do us if interfaces are still clunky?
What?!
How about realizing:
Since these apps are being written for free by people who want them, that's what they're going to write. These programmers aren't your peons to command. They're writing what they want to.
If you want an app, write it, buy it, or pay someone else to write it. Don't demand that people who are writing free software for their own enjoyment stop, and start doing what you want.
BTW....there are people out there writing word processors. Where do you think abiword came from? You, yourself listed four. How many word processors do you need? I probably have about 10 differenent apps to do this installed on my linux system right now. I only use one or two (Abiword and openoffice). You should go here and see how much free software there is availible for linux.
Life is too short to proofread.
There's nothing wrong with X. Most of the problems that people have with X don't have anything to do with the stability of X, they have to do with the API/toolkit, environment (KDE or GNOME), and/or the window manager. Those are the entities that "crash" the GUI. The problem is that a lot of newbies and even moderate users are not familiar enough with the system to understand this. They assume that because X disappeared off their screen, that X is to blame. I used to think this way as well, but after having gotten into Linux really in depth and compiled X a few times, I see now that the real culprit are the X clients, not the X server itself. The only thing the X server does that would lead someone to this conclusion is that it usually restarts: (Screen goes black, and X restarts, either resulting in just the X cursor on the checked background, or a DM pops up 'XDM, KDM, GDM, etc...' And, last not not least, if you are starting X with 'startx' (unmanaged), then yes... the GUI just disappears and takes you back to a *sh shell.) The latest realease of X actually has a lot of really great features that a lot of users are unaware of. Features that put it on par, if not slightly beyond the Windows GUI. (Mac OSX still has X beat :( ) Of course, the best feature hands down is the network transparency. Running X apps remotely and having them display on a local system is just great and much more flexible than Windows XP RDP. Especially since you can have applications running on several different systems all displaying on the same desktop (not in separate windows like RDP). Combine this with the Low Bandwidth Extensions (lbx) and you can do this over slow links with speeds that are pretty close to RDP. Your local X display becomes the main head for multiple servers this way! How cool is that?
Of course, there is plenty of antialiasing and subpixel shading (for laptops) that again is on par with Windows XP's GUI.
Overall, X is actually extremely stable, but ti does need a few improvements. I think the biggest flaw in X that makes people think it's unstable is that the session needs to restart when an app or client session dies. If X could be kept active and just allow the clients or apps to reconnect without ever going away, I think you would see a lot of people change their tune about X. It would also be nice if X allowed for reconnection of stateful sessions (Like XP allows for multiple users to be logged in with apps running). I'm not sure, but I think Xnest might allow for this, although I haven't tried it.
The biggest problem with X is that a lot of the extra functionality is not easy to use. lbxproxy (for low bandwidth connections) could use a nice GUI based tool combines with ssh to make setup really simple. For example:
1. You run the LBX Proxy Connector GUI on your local system. You enter the IP address of the remote system, select whether you want to run a specific app or a complete session (GNOME, KDE, etc...) and then click the connect button.
2. In the background the Proxy connector establishes an ssh connection to the remote system and executes the appropriate ssh commands to run the remote app or environment with lbx, and establish an ssh tunnel.
3. Locally, you see the app appear on your current desktop, or a new X display starts and runs the remote environment.
That would just be damn cool. You would get compression, encryption and either just the remote apps you need, or an entire remote session (KDE or GNOME).
So... please don't say that we need to get rid of X. Having alternatives to it that are useful in certain situations but X is a cutting edge and very stable/mature system that only needs a few utilities added to make it easier to exploit all of it's functionality.
Un-news
And if you want to share your windows apps with me I have to get wine, and that means windows is flawed?
Interesting case in point: Citrix servers can serve Linux clients. You don't need Wine to run stuff.
If you want an X app, you need X. If you have a crappy X client on your machine, that doesn't mean that X itself is flawed. You should replace your crappy client. I'm sure plenty of people here can suggest clients that will actually work.
Really? I'd like to meet said people. I've tried Exceed, Xfree86, MI/X, and WiredX. Do all of those suck? Why is it that they all have the same bandwidth requirements? I think bandwidth is always a problem.
You complain that you can't get a dirt cheap Xwindows solution for windows and you campare it to citrix in the same post. Is citrix free?
I want a solution where the CLIENT is free and easy to install (yes, the Citrix client is free). No, it doesn't mean the protocol is flawed if this doesn't exist, usually. But I think we can make an exception for X, because X puts such a burden of complexity on the client that it is difficult to make one.
I don't think you're being fair here. I'm running remote ssh-tunneled gaim from my home linux pc on a bsd machine in a computer lab a mile away. Both machines have X and it works. It's also not any slower than VNC would be.
Not any slower than VNC? Have you tried tightvnc? It requires about an order of magnitude less bandwidth than the original, and I have used it under the condition you mentioned as well as ssh-tunneled programs with X. Try running a web browser remotely. But that's another story. I don't want such a solution, as I said, because, like X, it is too primitive.
The fundamental problem with X is a lack of high level operations. The API should include calls like "make a button" and "open a modal pop-up box," and most importantly "display this bitmap" as well as the usual "draw a pixel."
Making this work isn't going to be backward compatible, at least not without making it even more bandwidth consuming. At least, thats how it appears to most people who have abandoned X. Perhaps someone clever will come along and figure out how to make the two ideas play nice.
It is precisely this flaw that leads to speed problems, which is addressed by both PicoGUI and Fresco. Unfortunately, Fresco was stupid enough to make all of their work require floating point ops, so they're going to have a lot of the speed problems that X does except on systems with a graphics processor - high end systems where speed isn't much of an issue anyway - and they'll still have bandwidth problems when they try to transmit pictures and other pixel-dependant info, since they will be transmitting fp numbers, making pixels larger than they should be. I think PicoGUI is very promising, however.
Mod me down and I will become more powerful than you can possibly imagine!
Fair enough.
I am not willing to give up remote display and the ability to use a lot of applications for this sort of improvement though. I make use of this all the time.
Your comments about OpenGL and X on Linux are true enough, but isn't this implemenation, not the core premise? Lets say the drivers were in working order. You then could do what you want without any hassles and remote it for free.
I have used X on other platforms, SGI in particular and it seems that a good X server can do all the things you would need. Maybe we are not there yet with Linux, but changing direction now still seems foolish to me.
Input devices beyond your basic keyboard and mouse are a pain in any UNIX environment. This experience seems to be true even in high end UNIX environments. We need more work there for sure.
If enough people share your view, then we might really see some change. If that happens, then I will roll with the punches and see what the new environment can do for me. Maybe it will be better!
Till then, I would rather see what we have right now work as well as it can.
Best,
Doug
Blogging because I can...
You know I like Linux a lot, Mandrake in particular, but I also enjoy and use on a regular basis, Win2K, FreeBSD and SGI IRIX. Does this make me a polybigot? :)
You are right about money. Linux on the server side is hot right now. The people responsible for that have a lot of experience in that area. Maybe graphics are the sort of thing that is a little harder. Maybe those bits of talent are not as well distributed as those for other tasks are. Maybe we are dealing with lame patent/ip issues. (Likely)
It seems to me that X performance and or (more likely) latency issues are getting some attention right now.
We have the movie studios using Linux on desktops, PTC is porting a serious 3D MCAD application to Linux. Go through the latest Siggraph proceedings. People are doing 3D with Linux all over the place.
Companies are investing in different parts of Linux because they see dollars. X is getting some of this.
Change will happen as I said in my original post.
Blogging because I can...
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.
Hmmm...last I looked GDK doesn't implement the X11 protocol....hmmmmm....
Sounds like it must sit a top it to me.
OK, I'll come out of the woodwork like every other worm that's lived, loved and hated X for years.
I think X was ahead of its time with the network view of a server accepting requests.
In hindsight, no fault of the original developers, the problem is now that it was implemented before the advent of newer standards in network communications such as http and XML. Yes, the existing infrastructure works like a draft horse. But it would have a better future if it didn't do things its own way but relied on other standards, even if those standards were later in coming.
And, honestly, X didn't flow smoothly into vector based (PostScript) and 3D systems (OpenGL) except as "extensions" that are obviously afterthoughts. Sun's NeWS didn't win. And OpenGL applications under XGL behave differently than pure X applications.
It would be nice if a new frame buffer device manager would be written that incorporates some of those ideas and yet retains the network awareness of X, which I think is one of its strengths.
A well-designed successor to X should be layerable either below X or above X during a transition.
"Provided by the management for your protection."
Go back and re-read it. As someone clever once said, the truth is insulting to a fallacy. Unless, that is, you don't know how to respond?
Want to Know How to Cheat the GPL? Read On!