Slashdot Mirror
Whitepaper On GTK+ For Linux Framebuffer
yuggoth writes: "LinuxDevices.com features a whitepaper about the upcoming GTK+2.0 support for the Linux framebuffer, which was mentioned on /. some weeks ago. Thewhitepaper describes architecture, benefits and limitations of GtkFB and also compares GtkFB with X based GTK+."
Only one word for this: Sweet!
I wish the GTK good luck, but after playing with QT embedded, I'm more then convinced that QT solution is much supperior to the GTK one..
;)
The QT solution got (among other features): ACCELERATED graphics speed on various chipsets - so the graphics are MUCH faster then simple plain frame buffer, Anti Aliasing Support (so you can read long docs with it without killing your eyes), You can play even movies with it (MPEG, Mpeg-2 - depends on the processor and the hosting graphics chip), and it's got a superior documentation compared what GTK got.
As for KDE - yes, KDE is way too heavy to run on it (specially if you run it on 486DX-2 with 16MB RAM), but you can run the KDENOX (Konqueror + some other stuff) without any problem on the 486 system I have described above.
And the most important thing - it's available now, under GPL while the GTK 2.0 got some way to go before it comes out as 2.0
Let the stupid flame war begin
blackbox under X will still run faster & with a smaller footprint (pun intended).
There is one. It's called "Insightful".
What do people think of Nautilus? I have been reading GNOTICES very closely and it seems many people hate Nautilus and don't want to see it go into GNOME! What will happen?
So don't use KDE. KDE is not a resource friendly system. Fortunately you can run functional unix desktops without all the Glitz that people seem to think you need.
Use IceWM, WindowMaker, BlackBox or TWM and you'll suddenly find that your swap usage is greatly reduced, the speed of your machine increases and the response of your desktop is much quicker.
KDE. Gnome. Enlightment. Very nice if you have ninja boxen but if you want to actually do something useful they provide nothing more than a slightly more coherent development environment.
My desktop uses IceWM. It's small, it's quick, it's configured how I want it to work. This doesn't stop me using KDE apps, it doesn't stop me using GNOME apps, it doesn't stop me using the vast collection of X apps. I know how to use a Linux workstation which empowers me to use those applications that suit me.
You can keep your DEs and Suites and all that utterly unnecessary guff. I want apps that use agreed upon formats and protocols. Then it doesn't matter what Window Manager or Desktop Environment I use.
Linux is about choice, right? So why are people trying to lock us in to just one Environment? Such things would be great if it wasn't for the way that people are all but brainwashed into thinking that if you use unix you have to have KDE otherwise it's all "too difficult".
I'm moving people from KDE to Ice or WindowMaker and the general reaction is "Hey, this is so much quicker and does what I expect!".
If you want Windows-On-Unix stick with KDE. We're trying far too hard to emulate Windows to try and win people over instead of actually working within the unix paradigm that many of us took as a reason to change in the first place.
Learn Unix. Use Unix. Drop Windows. Drop Windows philosophies.
is if you would read the article before replying and see how the topic is explicitly covered.
This could let me put a useful end user GUI app or two on the old 486/100 16MB RAM/800MB HD that's been sitting in my garage for a couple years. X is just plain glacial on it, especially with KDE.
Boxes like that will make great low end turnkey systems with all the benefits of Linux.
A white paper is supposed to cover all the technical inner workings and specifications of something.
This article was more of a reveiw than a white paper. It *was* interesting though.
Some moderator has a sense of humor. :)
I think you use a different library -- dynamically linked -- depending on what the display is, so that GGI should be fairly lightweight when most of its features exist on the target display, i.e., it reduces GGI calls to Xlib calls when as possible, and with KGI it passes as much on to the graphics card as possible. I guess this is similar to Open GL.
The framebuffer doesn't do this sort of optimization much, and I don't think it can do much of it because it has an interface that is more primitive than the actual device (graphics card) that it displays on. At least, this is what I understand. GGI on the framebuffer is very slow -- but probably just like GTK on the framebuffer will be fairly slow.
Thanks - it was KGI that I was thinking of, mainly.
:)
Too many TLA's
Most Unicies have a frame-buffer on the console. GGI is just a linux thing isn't it?
Sounds like the frame-buffer implementation would be a lot more usable.
How else would this be useful if you can only run one big "master app" ?
Well...for a component device that needs a UI (say a MP3 player that shows directories, images, etc... on the TV), this means that you can use GTK, but don't need X, which would help out with memory/cpu requirements.
- Qt. Covered, qt 2.2.3 supports AA text, and that means ALL Qt (KDE) applications inherit AA text by default. And if you happen to be a monkey and use KDE on your desktop you'll get anti-aliasing desktop wide, now! How's that, BeOS monkey? (since BeOS only has 1 toolkit c.q. DE all users are monkeys by your definition
:)
- Gtk+. Gtk+ 2.0 will bring AA support, which brings in GNOME and the rest of the Gtk+ World. This and Qt should cover about 95% of all apps.
- FLTK. Covered. This is important for the PDA market.
- Motif. Unless ICS or whoever is in charge of Motif today get their act together it'll be a while. Luckily, there are no Motif apps that I know of that suffer from missing anti-aliasing. Netscape? Nah, Konqueror burries it.
I'd say pervasive AA-text will be reality in 6 months time.-adnans (posting from a fully AA'd KDE desktop)
"In short: just say NO TO DRUGS, and maybe you won't end up like the Hurd people." --Linus Torvalds
I run xmaple with a heavily modified resources file with better (read: bigger) fonts. The changes are actually for all Motif apps. Still ticks me off thpigh that Maple uses MDI and uses MWM for the internal window decorations :)
:)
BTW, amazing how fast xmaple can be when run remotely using ssh compression. The Sparc box at Uni is a lot faster at running my stuff anyway + no hassles finding/installing/maintaining xmaple for linux
-adnans
"In short: just say NO TO DRUGS, and maybe you won't end up like the Hurd people." --Linus Torvalds
It was worth the wait, seeing it is totally royalty free! BeOS simply licensed their font engine from someone else (Bitstream?), which means that theoretically Be looses money on each free BeOS copy downloaded. Wonder how long they can sustain it...
As for your rundown of toolkits, what about Athena?
What about it? If you are using Athena apps, anti-aliasing is probably the last thing you should be concerned about
Also, if we now need a DE to get all the features of X, why bother with X compatibility anymore? We could just port KDE or GNOME to a new windowing system and have the same application base (with some tweeks.)
Oh, so we throw away X and just re-invent it again? Please! X development might have been dormant a couple of years ago, but man, it's going places today! I'm sick and tired of hearing how X is bloated and stuff. My Linux X desktop with NVidia hardware is *FASTER* than anything BeOS can come up with, and not just for 2D, 3D too! (oops, that was a low blow, sorry, OpenGL beta10 should be here anyday now right?). With RENDER becoming more widespread by the day you can bet your ass anti-aliasing will become more pervasive. I'm also looking forward to the RandR extension (Resize and Rotate), where you can just flip your display with a simple command. Think PDA's, tilt screen monitors, etc.. That's the beauty of extensions...
Anyway, nevermind that we got AA just a couple of months ago, fact is it's here, and it's free! It will prosper, wether you like it or not
Tell you what, you come up with free windowing system in the next year that allows me to run a web browser on a box that's half a world away, then lets talk about replacing X. Also, think about the following
- Pervasive (X runs on millions of desktops)
- Industry Standard. Think SGI, HP, Scientific community -> Universaties
- Open Source, anyone can hack it
- Official hardware manufacturer support. Convince NVidia, ATI, Matrox, 3DLabs, etc.. to write drivers for your system. Hell, even Be can't accomplish this right now!
- GLX / DRI. OpenGL for serious apps and games. Needs to be integrated in the windowing system, preferrably with remote 3D capabilities (GLX)
- Remote display. Should be fast and efficient (a la LBX). No need to buy XMaple when I can run it at University and view it on my desktop at home
:)
- Session management. And multi-user support too, don't forget security issues.
- Software base. Make sure it's compatible with at least gtk+ and Qt.
- Multi-monitor support. An X replacement would need to have this too. Good luck! For example, there is no Xinerama like functionality in BeOS, and very unlikely to ever happen since a rewrite of the app_server would be needed.
Replacing X with something better? Try it! The good folks from the Berlin-Consortium have been trying this for years, without much success. I'd say time and energy would be much better spend optimizing the current X architecture/drivers than to come up with a whole new system that will eventually be X.Now, where do I find an X server for my dual 133 BeBox??!
-adnans (posting from konqueror remotely over 100MBit ethernet, displaying on a PAL TV connected to a G400
"In short: just say NO TO DRUGS, and maybe you won't end up like the Hurd people." --Linus Torvalds
Would you settle for a mapping of Direct3D calls to Mesa's and GLX? Transgaming is working on just a beast. It's distributed as a Wine patch, and has been improving.
--
how to invest, a novice's guide
It should be noted that this is really targeted towards lower end devices. For big screens and powerful desktop systems X is still the way to go. Nice article.
GTK+ features a very nice feature of keyboard-bindings-on-the-fly. Simply move your mouse over the menu item (without clicking it), press the desired key combination - and there you have it. Wish to erase the combination? Move the mouse above the menu item, and press Del.
(Some have also criticised The GIMP for the multitude of windows it uses. Would it be better that The GIMP would open one huge window filling the entire screen (making you unable to do anything else on that desktop) and include a built-in window manager (which of course is not the one you would like to use) to manage the smaller windows, as is in Ph*t*sh*p and StarOffice?)
Maybe it would be better if the gimp could have a ui which was just a bit like gnome and kde programs? Menu bar, toolbars, etc etc.
Wasteful of main memory, wasteful of CPU data cache, wasteful of limited buffer memory on non-unified memory graphics boards, and VERY bad for people without graphics acceleration. The CPU will be doing a lot more rasterizing, even when it doesn't have to, and it generally isn't optimized for this. Basically, we can't yet be THAT inefficient.
Something like Rasterman's EVAS may be the right step towards this, though.
"It's overkill, of course. But you can never have too much overkill." - Anonymous Slashdot Coward
GTK+ supports this, just because GIMP doesn't use it, isn't a failing of the toolkit.
One perfect example of this is "The Gimp" program, which cannot be operated from keyboard at all. None of the menus have "hotkeys", there is no keyboard shortcut to bring up "the menu", and once the menu is up, it's impossible to navigate it except using cursor keys, which is much slower than if all the menus had hotkeys assigned.
In my opinion The Gimp is very well designed. Better than to have hotkeys for the menus, every action can have user-selected hotkeys (just hold the mouse over the action and press the hotkey). If every ALT-something combination etc. was used, the program would be a lot crummier. An example: I have set the my most commonly used tools to letters on the left side of my computer. I use the mouse with my right hand (or are you suggesting painting with the keyboard?) and have my left hand on the keyboard. Then I have 90% of the stuff I need without one single menu or button click - just one keystroke away. If only the menus had hotkeys, I'd have to remember that the paintbrush is ALT-tpp (or something) instead of 'f'.
What I wonder is why this feature hasn't been made an integral part of the toolkit. In all GTK+ programs you can set the hotkeys for menu actions, but in most programs they aren't saved. As for the built-in menu hotkeys, I hate them. For instance, I can't use ALT-w (which closes a Netscape window) to close XChat, because that opens the Window-menu.
Of course, the two approaches are not totally contradictory. It should be made possible to set hotkeys for the menus too. But IMHO the Unix philosophy of being able to configure it all yourself should not be lost.
(Some have also criticised The GIMP for the multitude of windows it uses. Would it be better that The GIMP would open one huge window filling the entire screen (making you unable to do anything else on that desktop) and include a built-in window manager (which of course is not the one you would like to use) to manage the smaller windows, as is in Ph*t*sh*p and StarOffice?)
I doubt, therefore I may be.
What is wrong with an UI that involves a little learning from your part and gives you a lot back in speed of use? Most applications I see never get any quicker in usability (you still have to go through all those windows to do this one action).
In the end its just what you like, for me I just get frustrated if I have to go any further than 1 window to change something.
"Who wishes to be creative, must first destroy and smash accepted values." - Nietzsche
Although I'm sure there are applications for GTK :)
under framebuffer, I tend to prefer to just write
things with access to the display buffer, and simply create my own blitting functions and
interface. Its a lot more flexible in many regards, and for simple programs that just need
to display a plot or a single updated graphic, its
a lot faster to code, and probably to execute. I guess this is more of an issue of what kind of interface one prefers, but I can't stand how so many program interfaces all look alike
Co-routines. =)
Be kind. There are too many mean people out there already.
Try the early 90's. For instance, SGI's OpenGL and X: An Introduction documentation from 1994 discusses GLX and refers back to papers presented at conferences in 1992 about running OpenGL apps under X.
What happened "a few years ago" (1999 to be exact) was SGI open sourcing their GLX implementation.
It's not like there's a tradeoff here; accessiblity is also nicely cleaned up in GTK 2, and goes well beyond keybindings to support screen readers and so on.
The point is a tradeoff, you punt multiprocess/acceleration in favor of smaller size.
If you want multiprocess/acceleration, you can use the small X server developed for the iPAQ, it's not very large, framebuffer with multiprocess and hardware accel and all that would be just as big as X. So then it would be pointless.
Another example is Gnumeric. In Excel, you can set the width of a column by typing ALT-ocw, entering the width in points, and hitting enter. In Gnumeric the equivalent would be ALT-oow, but it doesn't work because focus doesn't seem to shift after the second keystroke. So you are effectively forced to use the mouse.
I think the best user interfaces were in the late DOS era - WordPerfect 5.1 for example. Once Windows came along, standardization replaced usability. Unfortunately, Unix never had a strong tradition of well-crafted captive user interfaces (vi and emacs are the obvious exceptions) and so the Windows-inspired plague is washing over the Unix world with little resistance.
gtk rules, it has everything the way it's suppose to work. They have done a great job in bringing up this great lib. For all those gtk programes you the man.
I've been wondering the same thing. Why can't they be black or green papers?
The main limitation is the single-process model. All code in the system must be in the same binary and run in the same process.
That's a DOS-era approach.
It might make more sense to get behind OpenGL on Linux. That at least hooks you to the hardware acceleration. Admitttedly using the 3D hardware to scroll text is overkill, but it works. With today's systems, if it has a monitor at all, it probably has 3D acceleration.
As for hardware acceleration, it's possible to have the acceleration close to the CPU, rather than close to the display. AMD's "3DNOW" is in this category, as was Apple's QuickDraw 3D accelerator. NVidia may have won on display boards, but don't count Intel out yet for closer integration with the main CPU.
This is far simpler than classic window systems, which are a legacy from the days when we didn't have enough RAM to represent all the windows at once. There's a clear upgrade path from the current "framebuffer" approach to a window system like this.
GTK+ features a very nice feature of keyboard-bindings-on-the-fly. Simply move your mouse over the menu item (without clicking it), press the desired key combination - and there you have it. Wish to erase the combination? Move the mouse above the menu item, and press Del.
Which leaves 127 typeable characters (C-space C-a C-b C-c C-d ... { | } ~) and 127 more with the Alt key (C-M-space C-M-a ... M-| M-~). What if you have more filters installed than 254?
And still, how do you bring up a contextual (right-click) menu from the keyboard? (In Windows, it's Shift+F10 or the key between RWin and RCtrl.) Seeing as how some apps stuff most of their interface under contextual menus, this can get in the way.
All your hallucinogen are belong to us.
Will I retire or break 10K?
Which will result in a world without X-Windows. allthough remote-desktop functionality of X is cool, the X structure itself is pretty overkill, so IMHO it's a good move.
--
Never underestimate the relief of true separation of Religion and State.
SGI came up with GLX, but I don't think it was that long ago. I'm thinking it was a few years ago.
Just what the heck is a white paper? I mean, is there any sort of accepted standard, or idea of what should be in it, or is a white paper just whatever gets called a white paper?
Carousel is a lie!
it would be nice if they could unify the gtk sourcetree and combine all the different versions (X, win32, framebuffer, beos etc). last time i checked they were all seperate.
were you expecting to see a sig here? perhaps you'd rather see the inside of an ambulance!
DirectX is a MS Windows driver/library, and it is disgusting. Also, it's not cross-platform at all. About the closest thing you can get to Linux DirectX support is the Wine libraries. Do you have any idea what you are talking about?
Games should be written to be portable in the first place by using SDL / OpenGL.
-Justin
This is a pretty serious limitation. I didn't see any mention of a future change in the whitepaper, but there definitely should be. How else would this be useful if you can only run one big "master app" ?
I've used Qt/Embedded, and it works by starting up a host app (any app can be a host) which initializes the display and proceeds to run. Any Qt/Embedded apps to get launched from this point on will use the host's framebuffer.
For now (toolkit preferences aside), Qt/E will probably a more viable solution for handhelds, since it's A) Done, and B) has a good environment host application.
GtkFB sounds promising, but it absolutely needs separate process support. I don't think I missed anything about this in the whitepaper. Can anyone shed some additional light on this issue?
-Justin
because some of us have disabilities which make using the mouse very slow and difficult. my voice recognition software (which I have to use thanks to my RSI) can deal with keystrokes no problem, so applications with shortcuts and hotkeys are *FAR* more usable than those without -- and they should come with them preset, so I don't have to set them up myself. yes, at some point drawing will probably require a mouse-like device and my productivity will slow to a crawl. however, that doesn't mean opening files and running filters and so on should also require a mouse-like device.
Why don't YOU go back to drinking varnish, raping sheep, and watching the WWF in your trailer, moron.
Have you flamed SpanishInquisition t
Yeah, asshole. I just swam across the Rio Grande so I could secretly run your banking and entertainment industries.
Have you flamed SpanishInquisition t
I like the way X does remote displays.. just a while ago I was fooling around with OpenGL apps in a remote display, and got a remote to send it's accelerated graphics to my accelerated X server, and left the remote station to run the application process while mine ran just the video.
The idea at the time was something of distributed gaming.
I wonder if this new way of doing things will include such flexability ?
__________________________________
Free your mind - Flush your toilet
Games making use of OpenGL acceleration will still require X/glx but those 2D games would run pretty nice with this library with the added plus that coding for gtk is really nice. One question that some might answer, how do you manage keyboard/mouse events with the linuxfb?
Why would you want to operate a bitmap-editing program entirely from the keyboard, anyway? Control the brush using LOGO?
Hrm. I'm not a GTK programmer, so I wouldn't know- how hard would it be to allow an external application to call GTK menus via user-assigned hotkeys?
Try when you want to quickly access some feature, and don't remember the shortcut key.
Most people remember menu path, i.e. "Filters->Render->Flare" much better than a shortcut key for the same feature.
pretty pointless. to make things clear, I am referring to menu hotkeys, not shortcuts:
For example, on most software the "File" menu has
"_F_ile" F underlined, and is accessed by doing something like alt-f, then each following entry in the menu that comes up is underlined also -
"_N_ew", "E_x_it", etc, so you can do a quick alt-f-x to exit the program. This isn't a good example since most people would simply press Ctrl-X or whatever is the shortcut to quit it, but for long menu paths, using keyboard to get somewhere is MUCH faster than mousing or cursor keys (think that GIMP example)
_Filters->_Render->_Pattern->_Grid
Is only 4 key presses at the most to get to it, and a lot easier to type than move the mouse from each menu to another.
that's the problem. the toolkit does not support these kind of things properly.
For example multiple hotkeys on the same menu result in invoking the first menu with the matching key. Instead it should cycle through available menu choices. There are many other deficiencies related to keyboard accessibility.
Also, most developers today choose not to make their programs accessible to all users. Most current GTK/GNOME and for the most part KDE apps are not keyboard accessible. For some people it's a very important issue in accepting Linux GUIs.
developers should instead look into some of the problems the toolkit is currently facing.
One of the biggest problems is lack of "accessibility" features. Just try using any GTK app without using a mouse. Impossible, most of the time. Implementing accessibility features (menu shortcut keys, etc) is placed on the programmer, instead on the toolkit designers. There are numerous bugs and misfeatures when it comes to accessibility features in GTK.
One perfect example of this is "The Gimp" program, which cannot be operated from keyboard at all. None of the menus have "hotkeys", there is no keyboard shortcut to bring up "the menu", and once the menu is up, it's impossible to navigate it except using cursor keys, which is much slower than if all the menus had hotkeys assigned.
Why not just port GTK to GGI*. Sure, they haven't updated in a while--but with a big name project like GTK relying on them, maybe they'd get a move on.
(Note to latecomers: GGI is a display-device agnostic graphics API--it can use svgalib, framebuffers, X windows, X root window, even paper!)
*I just tried to follow my own link and found the I couldn't resolve the name. Google's most recent cached pages have dates from December. Is GGI dead?
--
324006
GTKfb and Qt embedded are both for small devices - embedded devices of course - where storage is very limited and advanced graphics cabilities are not required (such as your palm top computer or toilet management system (tm)).
Why bother.