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

Re:To answer your question

[Clue4All]

I don't understand. You mentioned plenty of papers of how X is atrocious and that it should be scrapped. Perhaps you haven't come away with a reason, but doesn't the fact that said papers exist mean that there are plenty of people who have one?

Sure, and after reading them, it becomes very clear that they site problems that are either no longer true or are just plain wrong. I was unimpressed with such papers.

1) Pay a lot for a decent X server for Windows (by decent, I mean that it doesn't put all X connections inside one Window with a fixed size, but rather creates Windows each time a call is made - unlike Cywgin xfree86).
2) Download, install and configure xfree86 with cygwin (assuming they've got the 200MB free for it). By the way, I know there is a version that is supposed to work without cygwin. It doesn't work yet, at least not right out of the box, and not with any instructions they give you.

You haven't done very much research, I see. XFree86 for Cygwin is excellent (90-95 MB, actually), and it features both a windowed mode and a rootless mode, which was added a couple months ago. I replaced 40 clients at work over the past two weeks that had been running an outdated version of Reflection X on NT 4 with Win2k and Cygwin/XFree86 (the Reflection version wouldn't even function on Win2k, requiring a $350 purchase per PC for the latest verison).

There is an X-compatibility module

[arcadum]

To quote It supports popups now, and uses a new hybrid rendering technique taking advantage of core X primitives, PicoGUI's built-in primitives, and shared memory.

Check out the screen shots for more.

Some "inside" information

[Anonymous Coward]

Dang, lost my /. password. But I am lalo, user and developer of PicoGUI for a few months.

Some information for the curious:

1. Micah (the lead developer) compiled some info at http://picogui.org/wiki/view/Main/PicoGUI and http://picogui.org/wiki/view/Main/FAQ
2. it is not X. It cannot run X apps. No way. Period.
3. 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.
4. 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:

1. a terminal widget that runs things like mutt, emacs, lynx|links|w3m
2. a web browser; porting mozilla sounds like the obvious choice
3. 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 alternatives ;-)

Re:To answer your question

[DeadMeat (TM)]

Have you tried WeirdX? Free, GPLed, and only 210K in size. It even runs on the crippled Java VM that ships with Windows.

Re:For the SI prefix challenged

[micahjd]

The name "PicoGUI" originated as a pun against other GUIs like Photon microGUI, Nano-X, and Microwindows :)

Re:What PicoGUI is and isn't

[micahjd]

We can, and probably will, run Qt and GTK apps on top of PicoGUI through some sort of emulation layer at the framebuffer level. But that would only be an emulation layer. It would give you none of the benefits that PicoGUI is designed to provide.

It is almost certainly not worth it to try porting Gtk, Qt, or anything else at the widget level, as PicoGUI's widgets are designed differently than most GUIs' widgets.

Re:X alternatives never materalize

[Wumpus]

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.

Re:Why I love X and will defend it to the death...

[t_hunger]

Yes, we all like X. But since Fresco was mentioned allrteady I'll step in on its behalf here. I knoe PicoGUI a bit and both projects are somewhat similar from the ideas behind it all (allthough with a very different implementation and emphasis:-)

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;-).