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]?"
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?
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
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.
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!
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
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.
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
"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)"
Well, I don't have moderator points, but I will say that (again) we are missing the ultimate point. Open source software development is supposed to be FUN. They think this is fun, or maybe useful for their stuff, or maybe both. That's plenty. People who are having fun with it will "give a shi..". Everything doesn't have to be take over the world. Unfortunately this article put it in those terms, rather than "hey, here's a cool little project."
Two applications I find potentially interesting for this are a) GUI installers that don't require X (serious overkill) and b) usable GUIs on really old hardware - make an interface to a few apps in picogui, make a mini desktop, stuff it on a 386/486, and ship it off to a country where computers are hard and expensive to come by.
For my money, the reason to replace X is not speed, but more power and flexibility and clean design. Hardware takes care of speed. That's why I'm a fan of Berlin. But until Berlin is done, X is great. But so are cool projects like picogui.
"I object to doing things that computers can do." -- Olin Shivers, lispers.org
You mean emacs doesn't ALREADY have a GUI in it?
"Evil will always triumph because good is dumb." -- Dark Helmet
Rootless mode doesn't seem ready for general use. It's only available in a server test version. Where Exceed effectively makes Windows the window manager, Cygwin/XFree86 has no window manager, at least by default, so I can't move the windows I create. Also the X server shows up in the task bar and non-intuitively only works if maximized, which you can't tell unless you click on it to see if it's maximized or not. I am sure these will all be fixed in time, but it can't be used as an alternative today.
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.
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.
Suppose you pick a non-biassed example and choose Microsoft GDI, Display Postscript, and X11R6. Comparing a high-level GUI toolkit to a low-level windowing system is an ineffective way to prove your point.
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.
... 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
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.
This is an interesting argument. Can you offer an example? I'd certainly agree that some X11 features were abstracted poorly. I would also agree that certain X11 features should never have been part of X11. But I'm having difficulty thinking of any problem with X11 that can't be solved with an extension. Some of these extensions might be difficult to write, but I'm optimistic given the number of excellent and timely extensions to XFree86 in just the past 5 years. Consider...
Do you see why I'm optimistic? Features have never been - and I will boldly claim will never be - a problem for X11. Features are added quickly and relatively painlessly by extensions. The features are integrated into modern desktop GUIs within a year or two. This isn't rhetoric or hope... it's established fact from watching KDE and GNOME.
So the only problem with X11 that would worry me is something so fundamentally broken, so fundamentally unalterable, and so fundamentally ingrained in everything about X11, that fixing it would involve a complete replacement of X11 with something entirely new. I can think of dozens of niggling problems but not a single fundamental problem.
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.
I do think what is needed is a new complete rewrite of the Xlib/Xprotocol layer to be modern. I do not like the fact that they keep adding calls or user-level libraries to make up for X's lame graphics capabilities. A clean lower level would be much easier to understand and debug.
The existing X interface can be emulated atop it. Most people would be happy with just an emulation Xlib that talks to the server by translating the old calls to the new ones. It does not have to be accurate (for instance it could tell the program 32-bit TrueColor no matter what the hardware does, and I'm sure the fonts will be named all different and be UTF-8 only, and it will not run any existing window managers. But this would allow you to run your old programs on the new system.
It may also be necessary to make an "XServer" for remote programs to talk to in X-protocol. This could be an independent program that translates the protocol to the new system. Without this you could not run programs from other machines that think they are running old X. This is not so important however.
I do not think a replacement for X will be successful without an Xlib emulator. This does not really preclude any design ideas. Even people who want widgets in the server (an idea I don't like, but there are arguments for it) will certainly provide the ability to create a blank window-sized "widget" and for a program to detect where the mouse is clicked and draw arbitrary graphics. X programs can use this for emulation. Yea, it won't look like the spiffy new widgets but at least the old programs work, which is really all that is needed.
All these systems have to realize how important Xlib emulation is needed and must work on it immidiately so that it is available the first day their system is available for use. Otherwise they will fail.