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]?"

Comments

To answer your question

[Clue4All]

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.

Re:To answer your question

[Minna Kirai]

As always, what you should use depends on your needs. If X works perfectly for you, then great. As a "frame-buffer oriented network-transparent graphics API" it'd be hard to beat. As the foundation for kits like Gtk and Qt (and even PicoGui sometimes) it works well.

However, as a platform (a standard for application creation) X is sub-optimal for users and developers.

The value of a standard comes not only from what it allows you to do, but what it forbids.

Suppose I write 3 programs to perform the same tasks under different GUIs: Microsoft's, Apple's OS X Quartz/Aqua, and X11R6. A Mac user can sit down without looking at the instructions and use his familiar old mouse motions, menu commands, and keystrokes with hardly a glance at the new stuff. A Windows(tm) user has nearly the same advantages. The icons for the same feature (Save, Print) look exactly the same, regardless of the program.
Of course that's not the case for X programs. Whenever I sit down at a new X11 program, I have to spend a few minutes recalibrating the basics ("How to I copy/paste, again?")

Because X allows the developer so much freedom, it deprives the user of the ability to anticipate how a program will operate. "The program can do nearly anything" sounds like an advantage, until you try to predict what a program will actually do!

Note that a weakness of Apple and Microsoft's GUI systems is that the "forbidding" part of their standard often comes in the form of "law" instead of "code". The taboos are enforced by developers getting chastised by the GUI vendor or the public when a non-ituitive program is released.

A weak method- the lag time for feedback is long, and if the offending developer works for the GUI vendor, he might insert loopholes into the rules.). But it produces superior results to X programs, where the users lack an imposing rulebook to point to as formal justification for their complaints. Improvements may happen, but there's nothing forcing them to converge on one way of doing things.

Some common responses to this argument:
"You want a toolkit, not X"
Maybe so. If a user's desktop could only run one toolkit, she'd never see an unfamiliar interface. This has the problem of discarding pre-existing programs, but argument-by-popularity is a logical fallacy (I'm talking about what solution would be best, not cheapest short-term). Better than using a single toolkit, though, is somehow allowing the application to be written independent of toolkit, and obeying whatever HCI conventions a particular user enjoys. PicoGui tries to do this.

"No one can be sure what the best interface is. Keeping flexibility gives us power."
In theory it does, but at the expense of accessibility. Too often it means that developers who don't want to be "HCI Researchers" find themselves wrestling with UI code that's entangled their applications.
PicoGui (and other "next-generation" UI systems) attempt to resolve this by keeping the application programmer further from the UI code than is traditional. (They haven't been totally successful yet)
He can't mess with the per-pixel alignment of buttons, because that's outside of the application's control.
This is fundamentally better than the way Apple and Microsoft's traditional Human Interface manuals have worked, because enforcement of the rules is done not by humans (punishing programs that act wrongly) but by software (doing the work for you, so it's guaranteed to do it right).

Re:A good alternative!

[Arandir]

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.

So what...

[Anonymous Coward]

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)

You can't really replace X

[mamba-mamba]

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
--

Re:You can't really replace X

[micahjd]

PicoGUI and Fresco are both network-transparent GUIs, so the argument that people just want to replace X with something that's not network transparent doesn't hold.

You say X is so low level it doesn't make sense to criticize it, but I think X has actually taken the worst of both the high-level and low-level worlds. X is low-level enough that you don't get any application consistency and you still end up sending individual graphics primitives over the wire. But, it's still high-level enough that it makes it hard to do some types of graphics operations. Yes, I know about RENDER. Putting aside all arguments on X's architecture, that still doesn't make it any easier to do things like blurring, multiplying two bitmaps, or rotation.

No. X is here to stay, just like it should be

[PotatoHead]

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 :)

X is fine

[dh003i]

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?

Re:A good alternative!

[Jeremiah Cornelius]

They've been at it for almost 20 years... 20 more years and it will be acceptably small and fast..

"They?"

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."