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]?"
It would take a reason to replace X.
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?
And doesn't that mean that perhaps an alternative should be considered?
My reason is that net connections require too much bandwidth. We use Citrix at school and get connection rates from Windows servers with than 2kbps needed. And it appears as though there is no latency in the connection, even though there is - i.e. it seems as though its running on my machine. Another big reason is that X requires so much from the clients. They have to be SERVERS themselves.
Also, the way it stands, if I want to share my X apps with my Windows friends, I have to get them to either
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.
3) Get them to use a non-windowing solution, i.e. VNC.
I don't really like any of those options, and that is why, for instance, there aren't a lot of X applications whose primary function is to be run remotely. Its why I won't develop any such applications - why I'm still sticking to using those less powerful gui kits like tcl/tk, swing and awt.
I yearn for something better than X, whether it meets your needs or not. If I could get a third of the functionality I get with a windowing environment, but also get those things, I'd be all over that in a heartbeat.
Mod me down and I will become more powerful than you can possibly imagine!
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
Here we see a common pitfall of debates about the quality of X- an overloaded word. "X11R6" strictly means just a low level drawing protocol. But, in the absence of anything better, it is also means the GUI system that runs ontop of that protocol.
This same problem happens in discussions about Linux. The strict definition is an OS kernel, but "Linux" has also come to be a blanket term for the whole family of Open Source operating systems that use that kernel. "Operating System based on the Linux kernel" is too long to use in everyday speech, so it gets abbreviated down to "Linux". ("GNU/Linux" is also too long, apparently)
So then, when someone attacks Linux (the broad definition), defenders can point to the specific definiton and dismiss the complainer on the basis that he's uninformed. When this happens, the debate is cut short, without a fruitful discussion of the merits of the problem.
Back to your point. You mention that for Apple's Aqua and Microsoft's GUI there are corresponding lower level APIs: DPS and GDI respectively. But this raises the question: What higher-level system corresponds to X11R6?
There isn't one. Or there's much more than one (Xt, Athena, Motif, Qt, Gtk, XUL, Fltk, WxWindows, TK...). Neither of those answers is useful as a starting point of discussing new GUI enhancements. You can pick any one of those toolkits and consider improving it, but then you're just addressing a fraction of all users (although maybe hoping that your favorite toolkit will rise to dominance above the others).
GDI and DPS are each found inside of one and only one GUI framework (architexturally a stack of blocks, instead of the branching tree of stuff that builds on X11R6). That's a consequence of monolithic developement instead of open systems, but it makes many things simpler on the users. How do you resize a window in Microsoft Windows? The answer is straightforward. How do you close a program in MacOS X? Another simple answer.
Neither of those operations is defined for X.
Only application developers are ever aware that DPS and GDI exist- they're completely hidden under the GUI. But users of X11R6 are frequently reminded of its presence. "Why isn't your program working? Did you check the DISPLAY variable? How about the xhosts? Ok, lets look at the MIT Magic Cookie..."
The world of Unix-like software can never have really great GUIs until X is invisible to average users. Maybe this means X has been supplanted by another system, or that it's just been relgated to the status of a device driver.
It's true that the competitor to PicoGui isn't X, but higher-level protocols. However the headline "An X Alternative" is not incorrect. Someday X's position as the premire "Unix GUI Application Development Platform" will be supplanted by something like Gtk, Fresco, or PicoGui. Then developers will begin to release software which runs on $NEW_DISPLAY_LAYER, rather than X directly. (Even though $NEW_DISPLAY_LAYER might still use X11R6 as a backend)
Someday a better UI environment will come around, when the only program allowed to connect to my X server is a single process from $NEW_DISPLAY_LAYER. It will enforce on applications the appearance and behavior that I want them to have, rather than leaving it up to individual authors.
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