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
Perhaps, but that's not the point.
Things like GTK and QT help lever programs away from the X server. Change just those and all the layers above will not notice the difference.
Not all X applications use GTK or QT, or even toolkit libraries at all! Any "X-killer" will have to accept connections from X clients. So it will have to know the X Protocol, in addition to any new "gee-whiz" features the "X-killer" has.
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.
--- Justin Dearing http://www.justaprogrammer.net/ We're just programmers.
i really get a bit frightened, even though i know gtk/gdk was started on linux and due to that got some linux-specific stuff even today, this Framebuffer-thing i evil towards the one of us that uses one of the different BSD-flavors. thec day they tell me i can use it on my bsd-box without starting x, then it will be a progress...
[toasters ? we don't need no stinking toasters!]
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)
There are a lot of misconceptions about Berlin.
First, one should realize that it overlaps with more than just the X server.
Berlin is different in that, unlike X, it doesn't communicate between client-app and the server by pushing pixels around. It's the responsability of the server to create a decent (looking) ui, based on the calls the app makes. The fact that those calls are made using CORBA, means they're network, and language independent (perl anyone?).
Using corba shouldn't be scary, in fact, Berlin is much lighter on bandwith in the case of remote display.
A Berlin app can choose the level of abstraction it needs... Some apps might choose/need to draw low level primitives, while others would want to be able to position widgets themselves, while even others just don't need/want to occupy themselves with how something might look, and just tell the server a specific "task", and let it handle it. If you want to get even higher than that, you should take a look here:
http://www.bucksch.com/1/projects/berlin/OOUI/
Why all these levels? Well, the higher level you go, the more freedom you give the server to implement a certain function in a particular way. For instance, a color picker might be almost unnecessary on a palm, and I can't think of better use of a 3d environment than mapping a 2D ui on a texture and displaying it in 3D. As i said it's up to the server (or one of its plugins)
Portability to totally different platforms doesn't always make sense; for instance, it wouldn't make sense to try to force 3d apps/models/vertices and the like in a palm; So if an app wants to use 3d models, it has to create them using a lower level 3d "kit" (which is just another server plugin). That way, the app writer can choose the trade-off.
Other things that I find important are: the resolution-independence (why are >1600x1200 or 640x480 displays almost unusable without heavy adjustments?); the fact that the policy is defined on the server (am i the only one that thinks "meta-theming" - making theme "packages" for different toolkits that go together - is a kludge)
Where does Gtk+ come in? Right now, Berlin sits on top of lower level graphic libraries (libart+ggi, opengl, others are possible). recently it's been possible to use GGI inside Berlin too... so that makes it: GGI on Berlin, on GGI on FB/X/glide/whatever (btw libGGI 2.0 will be out soon). Knowing this there would be 2 different ways of porting GTK+:
1) port GTK+ to GGI - additional benefits are that you get a whole lot of GGI "targets" gtk+ would work on. From what i hear GDK is pretty easy to port.
2) intercept the gtk widget creation calls and map them to the Berlin widgetkit. Advantage: gtk apps would blend in pretty well with real berlin apps, and have all berlin's advantages of being higher level and pixel independent. Disadvantage: i would think it would be _alot_ harder to do.
I guess the difference between the two is a bit (tiny bit) similar to the difference between Wine (api reimplementation) and running plex86 to run windows itself.
Now if Berlin's so great, why hasn't it taken off yet. Unfortunately, the best doesn't always win. DPS for X isn't there yet (dps.sourceforge.net), despite the fact that it's "proven to be good" by for instance MacOSX. (okay it's not entirely thesame but you get my drift)
A major problem with Berlin is that to explain the advantages, you have to write as much as i did just now. Once you know the advantages, it seems obvious that this is the way to go, but as i said, even the people who are interested don't always understand the advantages about it immediately. That means that few developers actually get into it, meaning slow progress and no critical mass yet.
Otoh, the fact that it has gone on for all these years, even when new good-looking ui tech came out, and that the developers still aren't giving up on it at all, proves that a) they're fools or b) they're onto something.
I definately don't think these people are fools. I believe it's one of the few OSS projects that is actually really innovating.
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.
Now THIS is a good idea! Goddamn installing mandrake takes me like 2-3 hours! Graphical installers and all, why not have a little game of tetris (or for mandrake, a "short" game of freeciv) running at the side?
Thank you! I'm typing this running X over my wireless network, I love X's remote capabilities. Furthermore, Xfree is certainly going in the right direction and isn't as bloated as is made out, anyone that hasn't really investigated xfree's efforts and is stating such anti X feelings certainly hasn't seen the progress thats been made.
For sure, X could be better in the speed department but what couldn't? It will always have to do things that a games console for example doesn't have to do (e.g. remote displays) but it's certainly NOT painful to use.
A journey of a thousand miles starts with a brutal anal raping at airport security
you will experience deja vu.
--
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.
you will experience deja vu.
--
(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.
Actually, "GTK+" is the correct name for what you're calling "GTK". GTK+ lays atop GDK. The "+" is documented in the GTK+ FAQ:
-rozzin.
GGI - the general graphics interface is a graphics API that supports multiple targets, including X, the framebuffer, ascii art rendering, and recently, an experimental MS windows DirectX target. Using a wrapper library would seem like a better idea because of the portability. There is an old GGI demo disk lying around somewhere showing that you can fit Linux+GGI in 1.4 megs).
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!
GTK+ looks to me to be a console graphics libary (as GTK is an X11 interface libary)
EyeCandy is the effort of the application...
I don't actually exist.
This is just great. It won't reduce the bloat that much. But this is pretty cool for platform with no X, or for ports (say BeOS, or Mac OS X).
In any case, reducing dependancies is nice.
(Extra bonus. As a X hater, this is good news [I don't really hate X per-see, but I hate the window manager concept, mostly because there are so much to choose from, and none correctly working out of the box, IMHO])
Cheers,
--fred
1 reply beneath your current threshold.
I totally agree!
If anything else is f*cked up in some way, the text console is my friend!
Also, what if the grafixlibs suddently are corrupt on boot, then what? The console is supported by the lowest lowlevel grafixmode, thus it is almost failsafe.
The console as president!
Eih bennek, eih blavek
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
Yes, but X doesn't take that much space actually. It's GTK and GNOME that take up all your RAM (and HD).
Monkey sense
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...
The kernel fb is (nearly or entirely) unaccelarated. It's certainly much slower than, say, an accelerated X server using DGA and friends.
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...
I use the aty128fb driver for my ATI Rage 128. It's significantly faster than the stock VESA buffer from what I can tell, but it's still pretty slow and laggy.
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.
That's what VNC is for.
I think this has already been done. If Berlin is still planning to use the GGI library, one could just run XGGI.
The "cue the foo posts in 3, 2, 1..." posts will commence with no subsequent foo posts in 3, 2, 1...
...LinuxBIOS or some other embedded Linux kernel.
Tetris on drugs, NES music, and GNOME vs. KDE Bingo.
Will I retire or break 10K?
Would this make it possible to replace X with a lightweight GUI similar to the GUI on the QNX one floppy distribution?
However, this does not mean that graphic design is irrelevant. It is very satisfying to look at good design. Making conscious choices with regards to design can be very challenging and is as much as a task / artform as programming itself. This is why an entire design industry exists.
This is terribly off topic, but the lack of what I consider good design is one of the things that turned me off of linux after using it ~2 years. Then again, on the converse side of the monetary unit, BeOS has what I consider good design, but not all the functionality in a web browser that I desire..
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. :)
Well, I believe his argument is: Why shouldn't GTK have a well designed default look (sans theme)?
Now we just need Gtk+ to run over VNC as a native network hextile protocol and all of those network devices could just have their pretty interfaces exposed to any viewing device on the network.
So could I surf on my Windows desktop at work looking at vncviewer running on my Linux desktop at home running on top of Gtk+/VNC displayed on my TV while sitting on my couch? (In the house that jack built)
I agree that the current default GTK+ theme is a little ugly, but you have to understand that GTK was made for the Gimp, and the Gimp was originally written in Motif, so the person in charge of how it looks was probably shooting for something that resembled motif.
Worry not, the new default GTK+ theme will look better, and be more customizable (IE up/down arrows on both sides of a scrollbar w/out using a hack).
He who knows not, and knows he knows not is a wise man
--
TO BUY A NEW CAR WOULD MAKE YOU SEXUALLY ATTRACTIVE.
PDAs owner will now be able to participate in the KDE/Gnome wars
Even NES emulator owners can participate with the GNOME vs. KDE: Battle of the Desktops ROM.
Tetris on drugs, NES music, and GNOME vs. KDE Bingo.
Will I retire or break 10K?
This is very good! It is great to have your computer boot DIRECTLY into a graphical enviroment NEVER never seeing the cursos blink!!
I dunno, but i like this a lot- i don't care about vesa hacks and shit, but this is great.
Looking for people to chat about multicopters, coding, music. skype: gtsiros
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
>Redmond have an answer. The answer is Get a job hippy.
Assumming every objector is a jobless hippy instead of realising a good number of them are high end admin is part of why Microsoft is throwing out FUD and insults instead of addressing users issues
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.
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
Jeeze looks like we have GTK Window without X-- what will they think of next? Oh, sorry, I was thinking of Microsoft... Seriously, this is a great achievement and may help to pave the way to more ubiquitous Linux usage, though.
LedgerSMB: Open source Accounting/ERP
Ok - technical aspects besides - why?
This seems to be typical of what is causing a lot of problems for Linux on the DESKTOP - in that there is too much choice and lack of cohesion in development.
Say what you like - but M$ did enforce only one DESKTOP design (not OS and internals etc.) - so from the position of the folk who might move to Linux - this is just one more thing that will complicated and cloud the choice.
Eye candy is one thing - but too much candy is bad for your health.
C-))
15 years ago it made sense to run apps on cheap terminals from a central server. You can bet the majority of X users are displaying graphics locally, so why not concentrate on improving performance? Everyone talks of making software modular so make the remote display part a module.
Only the State obtains its revenue by coercion. - Murray Rothbard
This computer lark certainly has a lot of big words!
-- Eat your greens or I'll hit you!
-- Eat your greens or I'll hit you!
GTK+ is already on WintenDOS 9x/NT. See also WinGIMP.
Tetris on drugs, NES music, and GNOME vs. KDE Bingo.
Will I retire or break 10K?
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
It would be more useful to be able to do something like playing GTK Tetris while your new distro is installing.
Not Tetris. The Tetris Company has not yet licensed the TETRIS® trademark for use on a UNIX® system or clone. This didn't stop tetriscloners from doing their job though; they simply changed the name to something like "Bricks 2000", "Bedter", "Quadra", or "Tetanus".
If you really want to impress the sheeple[?], use the TOD engine. With features from The New Tetris, Quadra, and Tetripz, plus split-screen support and cross-platform compatibility thanks to the Allegro library, it's sure to impress.
Tetris on drugs, NES music, and GNOME vs. KDE Bingo.
Will I retire or break 10K?
I think you meant to type 'crawl' up there in at least a few places where you typed 'run'.
Hay thar.
> last time I looked windows was
> x86 only, so was BeOS,
My Matthew says that although BeOS was also on Apple hardware until version 4 but with version 5 it was on x86 only. However BeOS has gone elsewhere since to several Internet Appliances under the name of BeIA (a different name - 90% of the same BeOS code). The moral of the story is BeOS is portable.
Now my Matthew has a gripe with you about your defense of X. It's quite obvious to him that you haven't looked into what X does and what it could do better. Do tell the community what you have programmed before... please!
X, by the nature of it's protocol, doesn't have many primitives that have to be worked around by abstraction layers. It can't map a polygon region to another.
The input device handling on X leaves much to be desired. In fact, the X server cannot instruct the client not to bother sending the X/Y mouse coordinates if it doesn't matter to the application. Some applications (like a flight simulator) require that all mouse movement be sent to the application. Others need only mouse clicks. But lets bog down the network anyway.
There's no nature of drag-n-drop (or even a decent cut and paste). Which I'm sure won't bother many people as who wants to drag from one application to another. But dragging within an application through toolkits would be useful. Imagine draging attributes to a email.
X's extensions are termainlly broken, too... honey.
My I'm starting to like this computer lark. There's so many loud people who haven't programmed the mess that is XLib and haven't seen how it could be better - yet they still marvel over X and it's fantastic remote display!
I could design a better remote display protocol than X's. There are many better protocols about already.
OK, that's all. X is awful. And please tell of your programming experience in X - I'm fascinated.
-- Eat your greens or I'll hit you!
-- Eat your greens or I'll hit you!
Just think, why bother booting the whole OS when you just need to get your Tetris fix
But that's not counting Tetris-compatible games that don't bear the TETRIS® trademark, such as Quadra and TOD: Tetanus On Drugs.
Tetris on drugs, NES music, and GNOME vs. KDE Bingo.
Will I retire or break 10K?
Because that's the name of the only chapter from the Unix Hater's Handbook that anyone here has read, because it's the sample they give out for free on the net. And, since JWZ and others wrote it, it must be true.
</cynical>
To be fair, it probably was more true in 1994 than it is now.
Become a FSF associate member before the low #s are used
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.
...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
Uh. X is currently taking 196.1% of my 128MB memory. But that's probably because I shouldn't believe top. (and that agpart memory gets added to the memory it takes)
. . . . . . .
may u!sh 2 sm!le at dz!z bad nn.!m!tat!ion
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?
must be too early in the morning, because i found this extremely humorous..
You are right. Infact the purpose of kgi+libggi was to be a media-abstraction layer. But nobody wants it.
And that's for the simple reason that only a few cards offer accelerated framebuffers. Try to configure the kernel. You'll see the list is quite strong. The vast majority of video cards need to use VESA compatibility modes. Those are SLOW. Anyone got a card that is accelerated in framebuffer mode?
Stop the brainwash
Okay, I know that you're a troll, and I know that I shouldn't be feeding you, but there are people out there who really believe the things that you typed.
Firstly, WRT gui innovation, I would like to know what is innovative about the macos gui, or about windows. I see tabs, buttons, scrollbars, toolbars, lists, trees, text entries. I see a application launcher, an application menu (start menu). Lets see, we have title bars, {close,{max,min}imize} buttons. I would really like to know what is so revolutionary about these guis. And don't say stuff like alpha-blended mouse cursor, or wavy-animated minimize function, or awesome pill button look.
Maybe certain applications utilize a unique gui with revolutional widgets, but as a whole, most of the applications I use on all platforms use basic elements which were around in the 80s.
Now, we've established that the widgets themselves aren't very special, so what about the gui as a whole? The Mac OS filemanager doesn't look revolutionary, the windows one certainly isn't (hasn't changed much, has it).
Please, I beg of you, give me some examples of how the interface one these other platforms wasn't either made in the 80s or ganked from another OS?
BTW the point of this post was not that these other interfaces are bad (OS X makes me want to own a Mac, as I played around w/ a beta of it at the store and it looked pretty sweet (first think I did was open a terminal)), but that just because something doesn't look completely different from everything else doesn't make it bad. I mean, do people bitch that bash resembles other shells too much?
He who knows not, and knows he knows not is a wise man
If I did what I think they did, you can use ANY of the syntactically correct themes at gtk.themes.org. Damn. So much for boring visuals.
Stop the brainwash
I think it would run better the other way around.
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 it would run better the other way around.
Just thought I'd give ya a heads up because the moderators are currently not responding to this excellent point. I think it's great that I can run a heavy app off a powerful server. If an app developed for gtk+/fb will work with gtk+/X, then I'll be happy. Otherwise, I'll be very very hesitant.
Stop the brainwash
It all depends on the theme and on the windowmanager. You can make all your applications look as if it were Win9x apps, or Beos apps, or whatever you call "eye-candy". It has nothing to do with GTK+ itself.
xer.xes -- 4181
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
"Homo sum: humani nil a me alienum puto"
(I am a man: nothing human is alien to me)
My only political goal is to see to it that no political party achieves its goals.
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...
Insted of Xterm to get a CLI maybe now this will let me stay at command line and run multiple GUI tools with it. More choice to work they way I need. I can't argue with that.
By definition, a government has no conscience. Sometimes it has a policy, but nothing more. - Albert Camus
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.)
Rendering stuff directly to the framebuffer is good, repeat, good. I used to hate X with a passion; that was before I started playing heavily with it and then started using more and more of its hardcore functions. It's pretty cool getting network and processor monitors on a remote Linux server to appear in a window on your Windows 2000 box and then later that day have them also show up on your Powerbook while you're at school. As a super duper GUI system X is really fantabulous. If you don't need that shit, you're still forced to use it. This is where X-less graphical shit comes in! If you can get GTK+, Qt and hitherto undeveloped GPL equivilent to DirectX to run directly on the framebuffer you've just gone halfway towards supplimenting X as a graphical interface for free unicies. X is great for alot of tasks but really sucks ass in others. There is a huge memory footprint as well as a fair amount of overhead involved with anything using it. Games and shit like handhelds don't need X or any of its neater features. They need a display system that gets right to the point. Good work the Trolls and the GTK dudes. GiPaq?
I'm a loner Dottie, a Rebel.
I know a lot of command line hacks out there who hate to use X, and usually don't even install the X packages. Many people don't want the overhead of X running, especially if they are running a server on an antiquated machine. It should definately be interesting to see what ideas people come up with......
I want my rights back. I was actually using them when our government stole them after 9/11.
Remember, this is GTK's CVS branch. It's got lots of nifty stuff.
IIRC, libpango is used to provide the antialiasing support.
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).
I have to sadly agree that the framebuffer is slow. Honestly, as far as I'm concerned, I'd like to see the companies supporting linux (if they're only going to directly support linux, such as nVidia or something) come out with a good framebuffer module for the kernel, and let us run THAT accelerated, and use the framebuffer X server on top of it. Accelerate the lowest level...it makes more sense (atleast to me).
Is there any reason we don't have faster framebuffer drivers?
But then, on the flip side I suppose that companies would rather suppose XF86 or whatnot and get faster graphics all around in the free OS world vs. just in linux...but then why do some companies (nVidia) provide kernel mods for other things...is a framebuffer driver that difficult to write? Hell, I'd even be willing to give a go at an nvidia driver in my spare time.
more likely the "anti-aliased" look comes from the screenshots being scaled down.
Of course, the kind of things that workstations get used for these days are nothing like what they got used for in 1985. It's a screwdriver in a world full of nails.
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...
Well, this may seems good for linux but if you thinking about saving disk space your and idiot! GNOME is very large as is, it's not going to fit on a floppy, or a handheld PC, etc. Besides, I don't see huge ammounts of support as framebuffer is a linux only project, other BSDs and free OSes don't even use FrameBuffer. It sounds like neat news, but it really doesn't have any killer app just yet. I always hear complaints about X, but I've not heard someone say they like framebuffer better!
Lets play gframebufferBill while Linux is booting - and see if Redmond has got an answer to that!
Kiwaiti
Member of the Legion Of Microsoft Haters
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.
This is really great! Getting rid of some of the overhead of the X Window system and running over the framebuffer is quite awesome.
I wonder how this will effect the use/implementations of embedded devices?
\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...
I think a great application for this would be a QNX-Demo-Disk type linux disk.. Basically, a low cost / low requirement Internet Appliance. The size/overhead/requirements of an X11 environment make this very difficult. But, if one could get a basic linux machine running, with framebuffer applications to provide the essentials (WWW, E-Mail, ?). Do it on a boot CD, or add network loading of other applications, and it could be a pretty slick little system.
I hope gtk/FB developers make applications compile in both X and FB environments. I have become very dependant on running applications on whichever $DISPLAY makes the most sense at the time.
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
How on earth is it that they've managed to get TT fonts (with AA no less) working with this when my friend and I spent the last two days hacking around with X, trying to do the same thing?
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.
Besides, if at all X is so darn bloated, it still runs pretty good on a 233 Mhz laptop with only 32 Mb RAM.
If this is true, then it would be great to have Mozilla (or other graphical browser) work without having to load up X (and your window manager of choice) every time you just need to check out a few web pages (yes, I could use lynx, which does a wonderful job at what it does, but lets be honest, lynx is really for those who have NO choice, this would give you a choice)
I think....therefore I am
I reject your reality
Ok, I was not starting a flamebait and I don't give a fsck about which one of KDE and Gnome will win...
Personally, I don't even use computers anymore, I am going back to using a typewriter and stamps.
In short, I could not care less about the embedded market! I was only joking.
Black holes occur when God divides by zero.
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
You should check out Links. I use it all the time! It supports frames, tables, cookies, ssl, etc.
Later...
KangarooBox - We make IT simple!
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..."
Yeah...
hit the <WRONG>button</WRONG>
"Flyin' in just a sweet place,
Never been known to fail..."
Like in every good old war, everytime someones conquers a new market, the opponent will follow.
;o)
But it's good to know that PDAs owner will now be able to participate in the KDE/Gnome wars.
Is this going to be the next big computer war? After Vi vs. Emacs, Unix vs. Windows, KDE vs. Gnome seems to be looking better every day.
By the way, don't bother flaming me, I am not interrested at all...
Black holes occur when God divides by zero.
No X = No X Window management.
Is this just meant for (a single) full screen app?
Now all people are happy because someone jumps over X and writes directly on framebuffer (BTW writing in framebuffer does not give you any hardware acceleration so it is not fast).
But some times ago some people made KGI + GGI. It was a good idea because it give us one thing : FREEDOM!!!
Freedom to choose what we use: do you like X? Use Xggi! Postscript? ggidgs! qt/gtk? made them for GGI.
Please note that with GGI you can use all things above in multitasking.
And KGI + GGI supported vga hardware acceleration.
Nobody helped them.
Then some one made dri and get full support by people, hardware writers. etc.
But you can use DRI _only_ with X. This is not freedom. This is microsofttish.
Now in this post read some people that write: "berlin is good but is not supported so do not use it or hope that it will replace X"
Remember: freedom! with GGI I can use X and berlin together.
Why you are so happy with framebuffer or DRI when there are people with better solution that do not get support???????
I repeat: who decide what is good and what is not????
now all we need to do is integrate AAlib so we can have crossplatform ascii graphics!
Freedom's just another word for nothing left to lose
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.)
$ runXClient xlogo
or anything like that...
Just out of curiosity, what makes you say it is less impressive than Qt/embedded? I don't ask that to start a flame war, but it seems to me they are shooting at (and apparently accomplishing) approximately the same goals. Why do you like Qt/embedded better? (Disclaimer: I have not used GTK+fb or Qt/embedded either one, but I have used both toolkits; I like the fact that Gtk+fb will not require application code to change at all, but I don't know where Qt/embedded stands on this issue)
--
"take the red pill and you stay in wonderland and I'll show you how deep the rabbit hole goes"
[]'s Victor Bogado da Silva Lins
^[:wq
Hrm...it's plain but...what about using the gtk theme engine? There are some snazzy and 'spiffy' themes for gtk that could really change the way those shots appear...
Greg Sanders - kfc@themes.org - Colonel_KFC
Greg Sanders - kfc@themes.org - ElCoronel
No remote display - this is NOT cool :(