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.
1) You can't say that Gtk was written to build market share quickly. Gtk was written as a toolkit for GIMP.
2) The reason that it is interfaceable with a number of languages, is because of how close it is to assembly language. Since all languages have to be "interfaceable" with assembly anyway, making them interfaceable with C is fairly trivial
3) I have seen other systems. My experience isn't overwhelming, but I've used Java, Delphi, and Gtk/GNOME. I liked Gtk/GNOME the best.
Engineering and the Ultimate
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)
You need write permission to /dev/fbsomething.
There is a PAM module that some Linux distributions ship with and that provides chowning files to a user upon login of that user at the console.
In the worst case, you could create a `framebuffer' group, give the group r/w permissions on the framebuffer device-files, and put some users into that group.
-rozzin.
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.
(Consider this circa 1993 in terms of how 'old Unix' businesses and users felt)
You know, I used to follow Linux. I was hopeful that it might provide the replacement for UNIX within my professional lifetime. I have since given up hope.
Linux 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 commercial UNIX, how are they going to persuade the industry to use it? There is a ridiculous amount of binary code written for SunOS, AIX, Ultrix, etc. To make any inroads they are going to have to have backwards compatibility with them, 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 Linux supporters 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 Linux from any commercial entities (even big companies like IBM).
If Linux 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 kernel system smaller, and more open, than commercial UNIX.
To bring this to a close, as "cool" as Linux 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 Linux. I do not think it will replace UNIX. My hopes lie instead with Solaris. There is much that can be done in the way of gradually extending Solaris, and deprecating old features. Over time, they can drift Solaris 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.
The lesson is: have patience, and contribute -- the rest will follow in time.
--
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
OTOH, I think it won't replace X11. I think the additional functionality it provides (remote display, integration of different toolkits, separate window management, asynchronous graphics) greatly outweigh any perceived or actual overhead or limitations of the X11 system.
To make any inroads they are going to have to have backwards compatibility with X
Berlin itself doesn't need backwards compatibility with X, it just needs someone to write an X server for Berlin. I display X applications on my MS Windows machines because I have an X server for Windows, this doesn't mean Windows has any kind of "backwards compatibility" with X. Windows has no knowledge of X. Berlin doesn't need any knowledge of X, just an X server that does.
wow, what a flamefest...
cduffy is right... and the only reason that widget sets CAN'T and AREN'T used it that THERE HAVE BEEN NO GOOD FRAMEBUFFER WIDGET SETS UNTIL NOW!!!
a framebuffer widget set __**IS**__ portable that's what my whole argument was!
As long as there are still 'legacy' X apps, you'll need to run X anyway
I don't really understand why people complain about X. X is nice, extensible, flexible and reasonably fast (both 2D and 3D wise with the event of Xfree 4.x)
Don't get me wrong, I'd love to see the architectural disaster that is X go
What architectural disaster? Able to run remote apps, use more than one monitor, infrastructure for 3D and 2D, works on nearly a zillon platforms (last time I looked windows was x86 only, so was BeOS, Others comes to mind easily)
It's not trivial to design an implement an system as large as X, but I for one think that the developers are doing just fine.
Hmm, getting offtopic here.
Gtk+ for framebuffer devices has it's place, but only in lowmemory situations and/or before the
system is really up'n'running (where I think another infrastructure should take over, X for example)
Thomas S. Iversen
uh, no... SDL has no graphical widget set (at least no good one
>>>>>>>>>>>>>
Uh, games don't use graphical widgets!
A deep unwavering belief is a sure sign you're missing something...
Its not an fb driver performance issue, it is the fact that fb is just that, the frame buffer. There are some drivers that implement hardware acceleration for the frame buffer, but others just give you memory area to write to.
X doesn't use the fb, (well, some versions do, but not normally) but uses user-mode drivers that use hardware acceleration.
Grub IS in the same position as Lilo. When the PC boots, it first loads the MBR. (In this case, part of GRUB.) Then, GRUB loads the rest of itself and displays the boot menu. Finally, it does stuff like switch into protected mode, etc, and allows you to load a kernel. The fb device isn't actually available until the kernel is loaded, and by then, GRUB is already gone. The only way to do GTK in GRUB would be to compile glib, GTK+, and the kernel fb code into the bootloader. (A scary proposition, since GRUB itself, at 37K is horrendously bloated for a boot-loader.)
A deep unwavering belief is a sure sign you're missing something...
You understated it. X runs perfectly well on my pentium 60, as well as my Multia, the ass-slowest Alpha machine you can buy. X is even acceptable on my AT&T Safari laptop (386sx-20), after the swapping is over. I don't know why people complain about X being bloated/slow/whatever. It certainly runs on hadrware I wouldn't dare to load Windows 2000 on.
This is ripe for PDA development, of course. And if AbiWord, Gnumeric and all could be run on a palm-sized unit, that'd be nothing to sneeze at. :)
You're still missing the point. Distros are what the users use. And no, distros should not be giving people that much choice. However, as the previous poster said, there is no such thing as too much choice. The user should never have to pick a window manager, that should be done by the distro. The should never decide that they want to use GTK on the framebuffer, the distro should not give them that option. However, saying that there is too much choice is like saying there are too many engines for cars these days. Well, you don't buy an engine, you buy a whole car, all put together. When you get in to engine shopping, you go to a mechanic, who _does_ know the details. Drivers should never pretend to be mechanics, either in driving or in software. However, the mechanics and manufacturers should have as much choice as possible.
Engineering and the Ultimate
Someone suggested that this could be used for playing games when booting. Good idea, but my Mandrake box takes about 30 seconds to boot. It would be more useful to be able to do something like playing GTK Tetris while your new distro is installing. Imagine the screen split in half, with blocks falling down one side and package info scrolling up the other side. Installing takes 30 mins - booting takes 30 seconds. Go think what one you'd rather play a game while waiting on.
Follow me
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.
joins the Embedded World... *stops playing Queen on his iPAQ and gets back to /.*
/. a couple of months ago (GTK Embedded, when the Trolls were talking about Qt Embedded) (PS, it was actually sad, i couldn't find anything on it afterwards besides the plain and simple page that was up, even a search on google turned nothing up)
:)
Like someone has allready mentioned GTK != Gnome, and if my memory serves me right, Gnome still requires X in one way or another, here and there.
But this doesn't surprise me, i've been waiting for this, with the hole, Qt Embedded, QPE, Konqueror Embedded on the iPAQ (and similar handhelds) allready released it was just a matter of time for GTK to finally (i may add) to get the code into CVS, this was allready posted on
But..i doubt i'll be going for the GTK solution (yet again) as the Qt solution is alot nicer for what i plan on doing for the ALFS (Automated LinuxFromScratch) Front-end graphical installer, but that's not a bad thing, at least now i have an even bigger choice when it comes to hacking for small resources/embedded devices! Qt Embedded, GTK Embedded, Microwindows are the three that are standing out so far (well that i have seen
I hope this continues, i'm going to love the next couple of months with the Trolls hiting back with something better then GTK doing the same *winks* (and vise-versa of course)
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
The GNOME team is working on exactly that - just check out Nautilus and Helix GNOME and Evolution.
The community shouldn't have a sense of direction. We are all individuals here. Direction should only be maintained (1) with the project maintainers (not the individual developers) and (2) with the dists. They are responsible for cohesion and direction on what they work on. Why should you tell me what I should work on?
Of course things in Linux look like copies of other things. Most innovation is incremental, not revolutionary. Revolutionary innovation is only practically realizable in incremental changes from the current place. The free software movement has only been really active for a short time, so we are coding to catch up, and then do incremental innovation from there. In the places where we didn't have 20 years worth to catch up, we are far in the lead (webserving, internet services, etc).
If you want current innovation on the UI front, look at Eazel.
The GNOME team has done a great job, I use GNOME/DIA/AbiWord as part of my job, and they work wonderfully. And, I'm running them all on a leftover PMac 7300. And I have the free software movement to thank for that.
Engineering and the Ultimate
...esp. what with fb support getting pretty good in the newest kernel. Not that you really need anything more than LILO-ish text, but there's something cool about "select OS, click "boot" to boot" (image button with a boot on it? ;^) ). I am aware that some projects to this effect exist already, but since this is essentially straight GTK+, it makes dev all the easier.
Actually, this would make writing a highly internationalizable boot loader a possibility, wouldn't it? Well, easier than reinventing your own multillingual wheel anyway.
And lets not forget that now a bootloader could have tetris in it, just for kicks. :-) Just think, why bother booting the whole OS when you just need to get your Tetris fix?
--
News for Geeks in Austin, TX
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.
One thing to keep in mind is that, IIRC, X11's memory usage displayed by top includes the portion of the video card's ram it's using (maybe all of it? Somebody mentioned this to me a while back and I never really dug into it.). So while this is memory the process is using, it isn't coming out of your system RAM.
--
News for Geeks in Austin, TX
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?
Only real problem I see is that you'd have to have your widget set installed on the machine with the X server; however, that could be worked around by falling back to a lower-level protocol (ie X as it exists currently).
I work for an embedded systems company currently funding some work on gtk+ (Michael Taht's "squashed-gtk", meant for display on tiny screens). I'd be unsurprised if we (or another such company) take the initiative in getting an integer patch done (any reason that such a patch couldn't be merged into the main tree? oh, compatibilty. ugh).
Frankly, it doesn't strike me as something which would likely be too close to insurmountable (and I've poked at gtk before, though not so recently).
I think you're missing the point. GTK+ isn't providing a framebuffer, GTK+ needs a framebuffer now, like SVGA-lib. Looks like GTK+ is going to blow back some life into SVGA-lib. If you want to run non-suid-root binaries that display graphics, I suggest you check out the efforts of the GGI project.
xer.xes -- 4181
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...
Better yet, why not target to SDL, which supports.... X, the framebuffer, ascii art, Windows GGI, DirectX, BeOS, (OS/2, IIRC), and GGI? Plus, SDL has built-in OpenGL support, which would make writing OpenGL GTK+ widgets/wrappers much, much, easier.
But glib isn't really that good. I mean, does anybody but me actually read the source?
For instance, if the system runs out of memory, an error is invoked. Now, the error handler exits with a message by default. I suppose there's some way to change this, but you had better exit, because at least some of the data structures do not check for success/failure.
In my mind, this means it CAN NOT be used for critical server applications, and probably SHOULD NOT be used for end-user applications.
Sure, it's nice for some things because of handy hashes, lists and so on, but it's not as well reviewed or specified as the things that Miguel de Icaza is comparing it to, like the standard C library or the POSIX API. (And to be sure, just use Perl or some other scripting language for anything that isn't a critical server application or an end-user application.)
What games do *you* play?
'Cuz when I'm playing FreeCIV or gnethack, I sure as heck see widgets. For that matter, when I watch my friend playing Everquest, I see widgets there too. (They're pixmap'd and thus don't look the same, but they're widgets nonetheless).
I suppose you could have a game without any widgets, but these are much more rare than one might think -- and it's a waste for game developers to write their own widget sets (as I've known more than a few to do, eg for XShipWars).
The X architecture is great in theory for remote administration, but you can't, for example, display a skinned gtk window from an app that's running remotely over a 10baseT network with acceptable performance. It should be the server that does all the drawing of widgets, the client should just run the main functionality of the app and send commands to the server to draw a widget, instead of creating a bitmap of a widget and sending it over the network.
Notice you're talking 10baseT. That's 1.2 MB/s. I haven't run skinned GTK apps, but I occasionally run adobe acrobat and netscape navigator without any issues (it's a 100baseT, but network usage never goes as high as 1MB/s).
And in any case, you can use compression on the link (either with SSH or with LBX (lbx is included with practically all distros out there)).
I partially agree with you that the client should draw the stuff or at least leave that as an option.
The problems are that:
1. That would make things much more complicated than they already are. Each lib would have proprietary commands for each set of widgets.
2. That forces the client to have the widget drawing library of the exact same version. That may strike you as simple, but it'd be a headache to sysadmins out there. Just imagine not being able to run some program because you don't have its library. Or worse, the library's proprietary AND commercial.
3. The client would use more CPU and RAM than without normal bitmap drawing. This isn't much of an issue today, but at the time X was designed this was absolutely crucial.
Flavio
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
This would be great for embedded systems where you need to trim the memory footprint down a little bit. For a general-purpose desktop computer, X11 is the way to go, because it's capable of running multiple toolkits, network transparency, direct rendering, and a bunch of other stuff - all at the same time.
But what if you're building the next Tivo? An embedded Linux system, on which you control the application software which will be delivered, doesn't need that stuff. GTK+ directly to the framebuffer removes some of the guesswork (indeed, with VESA it removes nearly all of it) and would bring about a lower memory footprint and faster time-to-market, while still allowing the developers to prototype the app software on regular GTK+ running on X11.
Kudos to the innovative GTK developers.
--
Tired of FB/Google censorship? Visit UNCENSORED!
One question though - what about the GDK functions? Will those be transparently wrapped?
--- Hot Shot City is particularly good.
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.
It is nice that gdk has been ported to fb, it will help get all the X depndencies out of it (which made the Windows port so hard). But gtk+ is not really ready for embedded systems as all the widgets are based on floating point. Arm systems (for example) have to emulate this in software so it is going to be really slow unless we write a whole new set of integeer based widgets...
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.
\subject... just FYI.
--
Sheesh, evil *and* a jerk. -- Jade
They're not standard GUI widgets. They are custom made in game widgets. They don't use the system GUI code (like GTK+ widgets) but draw their own directly onto the screen. CivCTP has widgets, for example, and it uses SDL. Thus, it must be drawing its own, non? Same thing for Everquest. The widgets aren't just pixmap'd (something that Win32 doesn't allow you to do) but are widgets that use the in-game event handling and drawing code.
A deep unwavering belief is a sure sign you're missing something...
That's right, and it's a waste.
/standard/ widget sets, just that they use widget sets. That they don't frequently use standard ones is unfortunate, as it's Yet Another Task that game programmers have to do. (And there /are/ still games like {Free,}Civ where standard widget sets are used... your blanket "games don't use widget sets" is wrong even if reinterpreted to refer only to standard widget sets).
I'd much rather see game designers using standardized widget sets where possible. (Incidentally, some game-targeted pixmap-capable widget sets are available for SDL, the windows port inclusive).
I never said games used
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
The framebuffer console is the replacement to SVGAlib. Instead of using SVGAlib as a means of doing graphics on the console outside of X, you can now just draw on the framebuffer console.
GTK+ sits on top of the framebuffer console...if there were no fb, GTK+ would then have to sit on top of SVGAlib. GTK does not use your video card directly as you said above. The framebuffer does.
How can you guys tell that this stuff is anti-aliased?? I personally, from the screenshot, can't tell. Remember, screenshots can be doctored because they are just another image file. On the other hand, it wouldn't surprise me one bit if I saw anti-aliasing in both this and X in all of the new 2.4 distros bound to be coming RSN since 2.4 is out!
Gorkman
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..."
No X = No X Window management.
Is this just meant for (a single) full screen app?
For ports, "this", in the sense of GTK+-fb, isn't relevant; what's relevant is that ports can be done, to a large extent, by changing the GDK layer, rather than by changing stuff all over GTK+.
I think the Win32 port, which antedates the frame buffer port, was also done largely at the GDK layer.
There are people working on a BeOS version of GTK+ - there's a GTK+ for BeOS page on the GTK+ Web site, and somebody's been sending patches to the gtk-devel mailing list.
Good thing there's no such thing as "X Windows" then... Go read your man pages, call it either "X", "X Window System", or basically just about anything else. There's nothing called "X Windows". :-P
/* Sesse */
(This comment is of course GPLed.)
most of that memory is pixmaps that the server is holding on behalf of the other apps on your system.
so, the earlier poster is correct when he talked about 'memory wrapped up in the X process'
The Matrix is going down for reboot now! Stopping reality: OK. The system is halted.