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.
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?
The entrenched X API is the biggest roadblock to projects like these. It's almost easier to put picoGUI into a new OS rather than trying to make it replace X in Linux/BSD/UNIX.
But if the X API can be put on picoGUI, then it's something to think about. Otherwise I'll stick with XFree86, which is getting faster and smaller with each release.
A Government Is a Body of People, Usually Notably Ungoverned
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)
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.
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
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.
The nice thing about putting widgets server side is consistency and performance.
1) Consistency, because all clients use whatever widget set the server does. By making the server modular, you can use FLTK for handhelds and GTK+ for desktops, and all apps will obey that decision.
2) Performance, because by interfacing clients and the server at a high level, you reduce communication between the two by a huge amount.
A deep unwavering belief is a sure sign you're missing something...
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 alternativesSay 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.
Blame the clunkiness of the linux desktop on the linux desktop, not on X (in general) or Xfree86 in particular.
There are a lot of concepts associated with X on linux. X, in the form of Xfree86, is at the bottom. Then on top of that there is a widget toolkit (i.e., gtk+ or athena or motif).
Interacting with X is the window manager, which may use a widget toolkit, and which excercises control over placement, size and other characteristics of application windows. Each of these application windows gets to decide how the pixels it has control over should look, within the limitations of the display device. And, in many cases, these applications are built on top of a widget toolkit which may or may not be the same as the one used for the window manager. Then there is the "desktop" which is really just another application.
So, you see, "X" is probably not the cause of the clunkiness you perceive.
On the other hand, if Xfree86 is genuinely too slow, then you should build (or clamor for the building of) a faster x-server.
But don't throw out the whole concept of the x-server, for it gives us many benefits, perhaps most importantly, network transparency.
And, by the way, most people are not saying "Why change? X is ubiquitous!" They are either saying, "it will never happen: X is ubiquitous" or they are saying "Don't change it, because there isn't a superior alternative yet."
I, on the other hand, am saying "don't blame X for problems which lie elsewhere." And, perhaps, "don't put forth an opinion on X if you don't really know what it is."
Oh, and, "the PicoAPI has something like 70 functions in it. Let's not get carried away!"
MM
--
By including this sig, the copyright holders of this work or collection unreservedly place it in the public domain.
The basic concept of X is sound, mature and very farsighted. We have some implementation work to do, but we also need to remember to keep that seperate from the actual value that X provides.
:)
Most people here like UNIX right? You can package all of those X complaints up and apply them to UNIX in general. When you do, Guess what? They are the same arguments. All of the things that make UNIX like systems, such as Linux, a good thing are the same things that drive some people nuts about X.
The reality is that using a *real* computing platform requires a little learning. In the last 4 years, the rate of improvement is astounding really. One or two more years and it is going to be solid.
X is a part of that work and brings with it some serious benefit. Again, I ask: "Why trash all of that, just so we can start all over again with a simpler and more limited system?"
It is not worth it.
There is a trade off between easy to use, and capable. You can also factor in common knowledge to understand how this applies to X today. Lets call this the "happy point".
Right now, there are a lot of people who got started not knowing what network transparent display systems actually mean. This is because the platforms they worked on did not have them.
So common knowledge is low for people coming to Linux right now. So the "happy point" is way toward the ease of use side of things. Makes sense really, because you don't miss what you don't yet understand.
Over the next couple of years a few things are going to happen that will essentially make this point moot.
X configurators will get done for most people. Most of the hard stuff will be abstracted into a few sensible combinations that people need and they will work. Progress so far shows me this will happen.
Some of the brighter ones will start understanding just what X is giving them and will start liking it. Articles, reviews and product feature checklists will start to mention this point.
Remember X is a serious differentator for UNIX like systems. It allows us to do things that make a lot of sense and provide a lot of value.
X server performance will cease to be an issue. There is simply nothing that prevents X from being as fast or faster than the very best frame buffer systems. Nothing. I have old SGI machines with simply *excellent* X servers. They understood X and made it work to its best advantage. The result: 30 Mhz machines that are just as snappy as the machines of today.
Don't tell me X is inherently slow. For each argument, I can point to the source of the problem and that source will be implementation, not the basic premise of X.
So all of this will help to raise common knowledge. As this goes up, that "happy point" will move over toward the capability side of things.
After a couple of iterations, we will wonder why it was such a hassle. I did when learning and it was harder then. Now it is fairly easy. In a couple of years, the things people want most will be in the GUI, for the rest of us, we can continue to meld X into performing whatever display task we want.
Only well planned scalable software with vision does this sort of thing. UNIX does it, thats why we like it, X does it, and that is why we will like it too.
I am *really* tired of hearing X sucks tirades. Is this bash X weekend or what?
Guess I will have to just post X is good tirades each time. Perhaps the truth lies between
Blogging because I can...
As many other people have pointed out, X is fine. Problems people have with "X" are really problems with either the implementation of X, or problems with their widget set. People complain X is slow. Now, X isn't slow: you're using a crappy implementation, or crappy drivers. Its not X's fault. Get better drivers, get a better or update implementation. Go to XFree86.org or try out Accelerated X. If you want a certain feature that's not there, its probably your widget set.
In short, before you say X sucks, identify your problems with it, and ask some experts about how to resolve them.
One thing that I will criticize X for, however, is that they don't enforce some kind of standard for interfaces. One thing Linux does need is standardized interfaces and key combinations between applications. There doesn't need to be one standard, but apps installed on a user's computer should all obey the user-defined standards. CTRL-V should always past...it shouldn't be CTRL-V or ALT-V or CTRL-P depending on the app. Same thing with menu's and stuff. Why should every developer have to reinvent the wheel? And why should the user have to reorient himself for basic key combinations for every program?
social sciences can never use experience to verify their statemen
Fresco... A friend of mine used to rave about it. I haven't talked to the guy in almost 8 years, which should give you an idea how long this thing has been kicking around. I've been following it for years (basically checking on the web page every few months), and progress is
.
s l o w . .
Don't hold your breath.
Anyone who's ever used an SGI would agree that they've made about as slick an X server as possible, largely because they've done such a good job integrating with hardware. It's smooth even on older computers, and the widgets (modified from Motif) look great. However, the underlying problems in X go way beyond the issues of specific implementations which shall remain nameless. Try reading the O'Reilly books like "Xlib Programming Manual" sometime, and see how long it takes for your brains to leak out your ears. Apple, on the other hand, has come out with a relatively consistent and polished API. Personally, I think Aqua is a bitch to actually use and prefer to deal with the clumsiness of Linux/XFree86 for running apps, but based on what I've read I'd much rather develop for OS X than Linux. I suppose I could use one of the many toolkits, but it'd be nice if I had one to choose from that didn't suck.
You got complaints with XFree development, then "throw your stone into the soup," with your own ineffable coding skills -- or hold your criticism. To work a weary truism, you look a gift horse in the mouth!
The XFree86 effort is about 10 years old. Twenty years ago (I was there) we had dedicated, proprietary VECTOR graphics terminals, one per PDP-11, please! Raster graphics were a dream, waiting for advances in (gasp!) bubble-memory... Never happened that way.
The XFree VOLUNTEERS took the X11r5-6 standard and reproduced it for free commodity systems. In six or seven years, they equaled proprietary vendor efforts, without the benefit of proprietary access to hardware! In the past three years, these developers have been working to advance X11 beyond any earlier realization.
X is a good design, and extensible enough to be with us still today. Sure, I would have been ecstatic if NeWS had prevailed politically in the 80's Unix wars, or that NeXT's DP had grown up - but the DEC committee won out for openness, and number of players invited to the table. The downside of comittee design: Xlib sucked, and every toolkit ontop of Xlib perprtrated the crimes. It's still just a library - better ones are here and arriving - if nonstandard. Even JZW's famous excoriation of X11 is based on Xlib and Motif toolkits, not X11 architecture or design features. These are not dismissable any easier than is Unix.
Paraphrasing the truism, I would advance that "Those ignorant of X11 are doomed to re-invent it -- badly."
"Flyin' in just a sweet place,
Never been known to fail..."
To explain:
- with X protocol, in order to draw, say, a pushbutton, the client says to the server things like : make a rectangle filled with color X, draw a line, etc... (the application programmers don't see this because this is what the GUI toolkits are for)
- with picoGUI, the client only says: draw a button. It's the server that take cares of details, according to the currently loaded theme.
This brings a couple of advantages:To come to your point, no, picoGUI cannont embed the X protocol (it would be against its basic approach). But il could be possible (though not easy) to make 'compatible library' that traslates GTK+ API (or QT API) into the picoGUI API/protocol.
Ciao
----
FB
With Fresco you get network transparency. We use CORBA to develop Fresco, so that's a free bonux. I know all those CORBA is bloated, jadajada, arguments, but I am confinced they do not apply to Fresco: We knew from the very beginning we will use CORBA and have taken its strength and weaknesses into account designing the overall system.
Anyway: Fresco is network transparent and it uses way less bandwidth then X. The protocol is so much more high level! The small demo we got only uses 1.9kBit/s to hold the connection with the remote server. I don't know any numbers for X, but VNC needs 800kBit/s when used to 'forward' the Fresco server to another computer via its protocol. It was using the same demo but with less then half the screensize the original server ran at. Not that the screensize does matter with Fresco. Of course I did the same things with the window (moved, rotated, shaded it, opened subwindows, etc.) using VNC to forward the display and running the Fresco server locally and having the client connect from the remote maschine.
Fresco allows for different 'WindowManagers' (of course we call them 'DesktopKit'). Those are loaded into the server and are not normal clients like in X, that's the basic difference.
You got a good point wrt. the decades of testing. Obviously neither PicoGUI nor Fresco can give you that. But then there's less testing needed: The servers have much less code. All the graphic-card handling stuff is separated out into libraries like SDL, GGI or whatever. Those have been thouroghly tested for a while now, makeing that critical component rather relyable.
Hardware support is not as bad as you imagine. Since neither PicoGUI nor Fresco (nor any other project in a sane mind) is writting graphic drivers themselves! There are excellent libraries, kernel modules, etc. around to do that. If there are only X-drivers, then you can still run on X-windows (it spoils the purpose of replacing X, I know:-) till one of the farious 'rip the drivers out of X'-projects is successful. There are several of those arround even now.
Finally you use the if it works, don't fix it argument. I like that, but obviously X does not work or there wouldn't be so many X-extensions getting actively developed. As I see it, you can either extend X (to Y or whatever you want to call it) or work on something new like PicoGUI or Fresco or some other project. In both cases you end up with a system where applications developed for it will not run legacy X-Systems (without considerable efford of the Programmer/Toolkit writer). Once you use an extension your application breaks for X-without-said-extension. So baiscally you end up with a system not 'forwardward' compatible with vanilla X, independent of wether you extend X or write something new. X-with-extension is of course backward compatible, but a compatibility layer can be added to another system later if need be. That's a lot of work, agreed, but the very simple case of just letting a X-server run in a window was allready demonstrated in Fresco.
Regards, Tobias
Some URLs you might find interessting: the Fresco Homepage, a short comparison of Fresco and X (the server is slow, please bear with it), finally a page listing among other things Other GUI Projects I found to be interesting for various reasons (both dead and alive;-).
Regards, Tobias
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.