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]?"
Well, actually, it seems that almost all desktop apps for Linux are written using GTK or Qt. Although PicoGUI is supposed to provide its own widgets and such, a Qt/PicoGUI and GTK/PicoGUI would ease the transition and make a lot of apps available under PicoGUI.
I would point out that on Linux, the picoGUI server and shared library, together, take under half a meg (487 kB) at their maximum size. Sure, it's not 1/1000th of a byte, but I've not seen an X server do that in a loooooooong time.
And how fast "could it be"? X11 seems to be faster than both GDI and Cocoa/Quartz on comparable hardware in my experience.
(any tweaking hints are welcome)
Most supposed performance problems with X11 seem to be due to the toolkits and desktop environment used. Gnome or KDE on X11 can be a bit sluggish on low-end machines Tweaking hint: use a different desktop environment.
Of course, you can also enable backing store by default in your X11 server, which is how a lot of other window systems achieve their slick look; backing store is disabled in XFree86 by default because well-behaved X11 clients shouldn't rely on it.
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).
Is your browser retarded?
Thankfully X has already fixed that problem. The new RandR extension will allow for this kind of resizing, and it is only a matter of time before all the apps that need to support it do (and there are a lot of ways to make it usable in the meantime).
Check out the slashdot story: RandR Extension
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 alternativesYou make the assumption that putting the widget set into the server ensures consistency, or that not doing it means GUIs become inconsistent. Experience with real-world window systems suggest otherwise.
Mac OS X ships with multiple widget sets that are consistent, and people use many more to develop on it. Windows, too, ships with multiple widget sets, and there are many additional GUI toolkits in use for Windows. Yet, most people don't even notice. That's the way GUIs work.
Performance, because by interfacing clients and the server at a high level, you reduce communication between the two by a huge amount.
I have seen no practical indication that client/server communication is a bottleneck for X11. Why "optimize" something that doesn't need optimizing? Furthermore, X11 already takes care of many widget-related issues, like geometry management, bit-blitting of retained pixels, and event dispatch. Basically, in X11, if you open a subwindow and draw some text on it, you already have a widget, and you can eliminate almost all client/server communications through backing store.
Have you tried WeirdX? Free, GPLed, and only 210K in size. It even runs on the crippled Java VM that ships with Windows.
-- 2 + 2 = 5, for very large values of 2
You may be right about the benefits of having a consistent look-and-feel.
;-)
But this has nothing to do with X. X is a low-level, display server technology. It has nothing to do with look-and-feel.
There is no reason related to X itself that we cannot have a consistent look and feel. All it would take is a concensus on the part of new developers. Also, if people are interested, they can always update some old classics (such as xv and gv) to use new widget sets. I have no idea how hard this would be, but I'm pretty sure it is too hard for me to take it on.
MM
--
By including this sig, the copyright holders of this work or collection unreservedly place it in the public domain.
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.
-- 2 + 2 = 5, for very large values of 2
> Cygwin/XFree86 has no window manager, at least by default, so I can't move the windows I create.
? twm is the default window manager, and it moves/resizes windows just fine. (I run cygwin & XFree86 under WinNT4.0)
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.
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
Wow, PicoGUI is pretty impressive.
Yes, but it's fundamentally different from XWT. I would not choose PicoGUI for an intranet. Hell, I don't think I'd choose PicoGUI for an embedded project. They decided to use their own protocol for server/client communications, which is something I don't understand/agree with. It's YAP - Yet Another Protocol. Yes, XMLRPC would have a larger overhead in terms of larger message size and a mini XML parser, but they could have used straight HTTP GET/POST, CORBA or something smaller and already out.
I also can't give PicoGUI to a web monkey and get them to design impressive widgets and therefore apps with it.
I'll stick to XWT, thanks. :-) And for embedded I would probably choose microwindows or maybe even fresco. The integer-only aspect of PicoGUI is nice but the reality is that anything that has a display requiring a more complex GUI will have enough horsepower to drive one of the bigger windowing toolkits.
For PDA use, you should consider porting "dillo". It doesn't do frames or javascript, but it can render most other sites and the executable sizes is about 230k.
Cygwin/XFree86 is excellent, not 90-95MB. Secondly, 90-95MB for a full set of GNU utilities plus X server is very nice, compared to the size of Reflection X or Exceed.
There's nothing wrong with X. Most of the problems that people have with X don't have anything to do with the stability of X, they have to do with the API/toolkit, environment (KDE or GNOME), and/or the window manager. Those are the entities that "crash" the GUI. The problem is that a lot of newbies and even moderate users are not familiar enough with the system to understand this. They assume that because X disappeared off their screen, that X is to blame. I used to think this way as well, but after having gotten into Linux really in depth and compiled X a few times, I see now that the real culprit are the X clients, not the X server itself. The only thing the X server does that would lead someone to this conclusion is that it usually restarts: (Screen goes black, and X restarts, either resulting in just the X cursor on the checked background, or a DM pops up 'XDM, KDM, GDM, etc...' And, last not not least, if you are starting X with 'startx' (unmanaged), then yes... the GUI just disappears and takes you back to a *sh shell.)
:( ) Of course, the best feature hands down is the network transparency. Running X apps remotely and having them display on a local system is just great and much more flexible than Windows XP RDP. Especially since you can have applications running on several different systems all displaying on the same desktop (not in separate windows like RDP). Combine this with the Low Bandwidth Extensions (lbx) and you can do this over slow links with speeds that are pretty close to RDP. Your local X display becomes the main head for multiple servers this way! How cool is that?
The latest realease of X actually has a lot of really great features that a lot of users are unaware of. Features that put it on par, if not slightly beyond the Windows GUI. (Mac OSX still has X beat
Of course, there is plenty of antialiasing and subpixel shading (for laptops) that again is on par with Windows XP's GUI.
Overall, X is actually extremely stable, but ti does need a few improvements. I think the biggest flaw in X that makes people think it's unstable is that the session needs to restart when an app or client session dies. If X could be kept active and just allow the clients or apps to reconnect without ever going away, I think you would see a lot of people change their tune about X. It would also be nice if X allowed for reconnection of stateful sessions (Like XP allows for multiple users to be logged in with apps running). I'm not sure, but I think Xnest might allow for this, although I haven't tried it.
The biggest problem with X is that a lot of the extra functionality is not easy to use. lbxproxy (for low bandwidth connections) could use a nice GUI based tool combines with ssh to make setup really simple. For example:
1. You run the LBX Proxy Connector GUI on your local system. You enter the IP address of the remote system, select whether you want to run a specific app or a complete session (GNOME, KDE, etc...) and then click the connect button.
2. In the background the Proxy connector establishes an ssh connection to the remote system and executes the appropriate ssh commands to run the remote app or environment with lbx, and establish an ssh tunnel.
3. Locally, you see the app appear on your current desktop, or a new X display starts and runs the remote environment.
That would just be damn cool. You would get compression, encryption and either just the remote apps you need, or an entire remote session (KDE or GNOME).
So... please don't say that we need to get rid of X. Having alternatives to it that are useful in certain situations is fine, but X really is a very cutting edge and flexible system that needs a few "ease of use" apps added to it.