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.
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.
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?
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.
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.
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..."