Slashdot Mirror
GTK+ without X!
Rayban writes: "Just noticed on news.gnome.org that the Linux framebuffer support for Gtk+ is now in CVS. This means that you can now write a quick Gnome app that doesn't require X at all! Imagine a Gtk+-based distro installation that can run solely off the framebuffer! No more VESA hack and a significant disk space savings - maybe even a Gtk+-based bootloader? The screenshots are here, here and here."
Obviously the screenshots aren't very special, but I'm having no problem thinking of interesting, useful tasks for this.
This would be a long overdue replacement to Svga-lib.
The one (and only) virus for Linux was made posable in part becouse of svga-libs need for super user access... (and users swapping binarys instead of source code)
The other problem with svga-lib is it's just an interface into existing svga cards... This is useless on platforms that don't use the obsolet video chipset...
But console graphics are the key to making linux games run faster... X11 uses a lot of memory and runs slow.. it has support for stuff that games don't need.. Window managers have stuff games don't need.. Strip all that away and the computer is many times faster..
Something like GTK+ would use your PC 2D rendering card directly instead of using it's internal VGA emulation.. It would allow you to run with less memory and give more speed to your games..
Also GTK+ has the added benifit of being GTK.. It would be pritty easy to port GTK code to GTK plus (and visa versa).. It should work equally well the Mac as it dose on the PC.....
While svga-lib dosn't have that requirement to give your games superuser access.. it's still long overdue for a replacment...
I don't actually exist.
uh, no... SDL has no graphical widget set (at least no good one)
presumedly GTK+ in combination with GGI or SDL (as the article says "the linux-fb port of GTK+") would just put the GTK widgets on your framebuffer...
actually, this something I was looking for a while ago (SDL + GTK = a platform independant widget set/window manager)
Of course, you can simulate all that stuff in C or C++: systems like COM try to address some of those issues. The problem is that if it isn't built into the language and runtime, everybody does it differently, the compiler can't help you, and you still don't get fault isolation.
Miguel could have done a lot for "Making UNIX Not Suck" if he had chosen a better language and runtime. His choice represents merely another pragmatic compromise in a long string of pragmatic compromises made in the industry. Gnome is well done, it works well, it has lots of functionality, but fundamentally, it merely "sucks less" and doesn't avoid the problems that are at the root of the problems with most UNIX and Windows software.
Of course, if Miguel had chosen differently, Gnome would not have become nearly as successful, since it mostly depends on the willingness of others to volunteer. Some other C/C++-based environment would have caught on. Ultimately, the "sucky" state of UNIX and Windows software is the result of the choices we all make day-to-day. Maybe we can make it a millenial resolution to use other languages and runtimes more: Java, Oberon, OCAML, Modula-3, C#, Eiffel, Python, Scheme, etc. Given that Gtk does bind pretty well to most of those, we can even stick with the Gtk toolkit.
Did you really look at the screenshots before posting this? Take a look at the anti-aliasing of the fonts, rendering of Hebrew and Arabic characters, bi-directional text and other features. I honestly do not think that some other toolkit has been doing this for ages... (anti-aliasing yes, BiDi no)
Another minor point: Qt/Embedded is released under the GPL (or Qt Professional Edition license), while GtkFB is released under the LGPL. This makes a big difference if you want to develop a commercial application. This difference can be better or worse, depending on your point of view.
I'd love to see the architectural disaster that is X go
Why do people keep saying that X is an architectural disaster?
I think this is one more example of false ideas that somewhat became mainstream and keep being repeated in a drone fashion.
Of course X isn't the most optimized application around, but I seriously don't see how it's an "architectural disaster". Most people don't remember that the whole point of X is to run applications in a network environment, even if they're used locally.
It's fine with me if you don't use even half the functions X has to offer you, but don't call it a disaster because of that.
Flavio
Gtk+ is a very well designed piece of software. Moving it to xyz platform is actually quite easy compared to most windowing toolkits.
This is because of a thing called gdk. gdk is the abstraction layer that gtk+ uses to talk to a windowing system. It feels a lot like Xlib, but isn't. The most important differences are: it uses glib's more advanced data structures; it provides more robust error handling and it also permutes the XEvent system into glib/gtk's thread-safe "signal" system (not to be confused with POSIX signals).
There are limitations, however. gdk must get its fonts from somewhere, so I suspect that this code still requires an X font server. That's not so bad, as xfs is pretty light-weight compared to the X server.
Personally, I just wish more of the code out there would start using glib and Gnome for things like error handling, internationalization and configuration preservation. Even non-graphical programs can benefit from complying with the Gnome application standards.
I am by no means an expert, but it seems there are some bad ideas floating around here.
Firstly, this is not gtk+ becoming bloated. If it's been done in line with how gtk+ was originally written, the framebuffer support is not actually in libgtk+ but in libgdk. libgdk is a later below the widget set itself, and until now has been a fairly simple wrapper around x primitives. No doubt, gtk+ has also changed because of this but don't expect to see X specific or framebuffer specific or anything else specific code in libgtk+ itself.
Secondly, I think the article is not correct to say you can now write a gnome app. I might be wrong, but i believe gnome requires X right now which i believe is a design mistake due to lack of orthogonality. (Note: I havent looked at gnome for a long time, so I may be wrong - apologies to gnome developers if so)
-- MartinG To mail me: echo kewyjlcxyzvjfxbqwh | tr bcefhjklqvwxyz
Ah, but framebuffer GTK+ will never be as cool as Berlin. If you're bragging about its ability to do anti-aliasing and other fun stuff like that, Berlin does cool alpha channel stuff, does IPC using CORBA, and it does Unicode. Its kind of like X, but it really isn't, but it's better.
Go ahead and flame away. I'm ready for it...
Kan jeg få en pils, vær så snill?
Until LILO has a framebuffer (my guess: never), you cannot use this in a boot loader.
Corel made a graphical LILO replacement, which simply used video memory to draw the graphics. There is no room in the bootsector to load GTK, Qt, or GGI.
Wow, I'm surprised. Even for Slashdot, there is a lot of misleading and incorrect information here...
Well said. Miguel de Icaza made a similar point in his paper, Let's Make Unix Not Suck : in general, component reuse in Linux just isn't happening beyond libc and xlib, whereas this is something that IE actually does right-- it's built of a collection of reusable COM components. Much kudos should be accorded to gtk and friends for having a policy of software reuse that goes beyond the merely graphical.
It'd probably be offtopic here to consider whether applications which don't share components with others (MdI lists Samba, Apache, NFSD, innd, sendmail, in.named, ftpd, ssh, Netscape, GhostView, XDVI, Acrobat, Mathematica, Maple, Purify, FrameMaker, and Star Office) could or should be redesigned or patched to make use of glib as well; but it's ontopic to agree with you about the benefits of glib's reusability, and indeed to add that the use of glib is IMO something that should be considered carefully if anyone's starting a new project in C.
GROGGS: alive and well and living in
You know, I used to follow Berlin. I was hopeful that it might provide the replacement for X within my professional lifetime. I have since given up hope.
Berlin development is moving at a snail's place. They don't have just a whole lot of people working on it, and I'm not sure they have *anyone* working on it full time. While the attempt is certainly noble, I don't think it's going anywhere.
More importantly, even if they manage to finish the project and come out with a reasonable, clean replacement for X, how are they going to persuade the industry to use it? There is a ridiculous amount of code written for X. To make any inroads they are going to have to have backwards compatibility with X, in which case they've moved to a new house, but carried the old baggage with them.
I certainly do not believe the commercial Unix vendors are going to embrace such a new development. Would the free Unix distros be confident enough to break compatibility and go their own way? I don't see the balance of power between open / commercial shifting that quickly. And so far I have seen zero support of Berlin from any commercial entities (even companies like Red Hat).
If Berlin is used, I expect it will be in "fringe" applications first, not mainline workstations. Particularly, embedded applications might pick it up. They have a much smaller pool of software to tote around, and would probably be happy to have a graphics system nicer, and hopefully smaller, than X.
To bring this to a close, as "cool" as Berlin's feature sheet may sound, the software is far from complete, is advancing slowly, and will face serious obstacles once it *is* complete. I, personally, have given up hope on Berlin. I do not think it will replace X. My hopes lie instead with XFree86. There is much that can be done in the way of gradually extending X, and deprecating old features. Over time, they can drift X towards a cleaner system, relegating cruft to libraries which get loaded less and less often. This is less inspiring, but probably more feasible.
Three reorganizations are worth one revolution.
--Lenny
There's one very common misunderstanding about the framebuffer: Speed. People seems to think that fb is fast because it talks directly to the hardware. It is not. In fact it is so painfully slow that anything resembling normal X resolutions and colordepths will be a horrible experience. Just try running an actual graphical application on fb, it will feel like java on a P166.
Where it could get interesting is if this would change for the better. There's no reason that the kernel drivers for fb couldn't be faster than they are right now. One problem would of course be that good drivers will have to be written for both X and the kernel where presently the kernel drivers are extremely basic. But when you start wanting 3D drivers, network transparency etc. you'll end up with something just as big as X anyway. (And having X or something of it's size in the kernel seems like a very bad idea.) The reasons for replacing X has nothing to do with speed or memory use.
When Qt embedded was GPL'ed and later when Konqueror embedded was released, there was a LOT of people talking about running KDE on fb. The speed problem alone makes this unusable for now, but even if this could be solved, KDE classes use quite a lot of X calls to perform as fast as possible. While it might or might not be as big a problem with Gnome, you will still have the situation where you now have two different underlying implementations which is much more awkward than just using X natively.
One place this will definately NOT benefit is LILO. The framebuffer is implemented by the kernel and LILO is used to load the kernel. This means that there is no way LILO can ever use the kernel's fb implementation. At least not unless someone finishes the kernel-in-bios hack but that's someway off in the future yet.
X runs even on the Compaq iPAQ, so that proves that X isn't bloated...
... sometimes I fly with the white swan to my Liffey home.
GGI, SDL, and Qt have been doing this for quite a while. Actually, when the framebuffer was added to the kernel (a long time ago) documents popped up about how to treat it like DOS int 13.
SuSE and Caldera's installers use Qt under the framebuffer.
Personally, I think SDL is a better fit than GTK for games. I downloaded the CivCTP 1.2 patch and the release notes mentioned that you can run it from the console now without X. It's experimental, though.
Alex just posted another screenshot to gtk-devel-list. This one is of dia, and is a little more interesting then the ones above.
http://www.lysator.liu.se/~alla/files/diafb.png
GTK rendering without relying on X.. is that a step towards something like porting GTK to aqua, as is necessary to run the Gimp and other GTK apps natively in OS X?
there's a short but informed discussion of such efforts at macgimp.com and i wonder if anyone here might be able to shed some light on whether this is helpful in that effort...
- Entertaining Bits from the Ancient Kernel Tree
1. As long as there are still 'legacy' X apps, you'll need to run X anyway;
2. If GTK+ gets 'enhanced' to do some handy things X does right now (like, oh, IPC/RPC-based stuff), won't it just become another X, minus the compatibility with zillions of existing apps?
Don't get me wrong, I'd love to see the architectural disaster that is X go, but I'm not too sure that GTK+ is the right way to achieve this...
Every font is anti-aliased, as are many of the lines, etc.<p>
I also see that the test is not only multi-lingual, but there is advanced <b>BiDi</b> and unicode support with dynamic keyboard re-binding. This evidenced by the Hebrew and Arabic in menus, forms and text fields.<p>
I think that this means that Pixbuf and Pango are along farther than I thought, and that a simple lib swap gets about any Gtk+ app/library running on the fb.<p>
"Flyin' in just a sweet place,
Never been known to fail..."