

Whitepaper On GTK+ For Linux Framebuffer 99
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!
Whats wrong with QT Embedded? (Score:1)
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
the sad thing... (Score:1)
Re:Whats wrong with QT Embedded? (Score:1)
It's trolltech proprietary. Sorry you gotta fork over the big bucks to use qt embedded. You also have to fork over the bucks to use qt in a proprietary application (not with gtk -- lgpl).
While qt embedded might be superior, it most definately is not Free software. Sorry try again. Insert another Coin. Might as well make a good free software solution and route around the trolltech tax authority. Hence gtk embedded, which I predict will take off. Then all of a sudden, suspicious thing happens. QT-embedded becomes dual licensed GPL and qt-proprietary. So if you want to code proprietary apps on it, the Trolltech tax authority still gets to sip from the gravy train. Now, I'm not for proprietary applications, personally, which the GPL should, in all honesty prevent. But when trolltech disingenously dual-licenses their stuff under the GPL, it's done for the sole purpose of protecting their proprietary money supply, otherwise they would lGPL it. long live gtk and GNU.
Re:We'll finally get rid of the X! (Score:1)
To Go Offtopic, But To Talk To GNOME. (Score:1)
Re:Very cool (Score:2)
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.
what would be even better (Score:1)
Very cool (Score:1)
Boxes like that will make great low end turnkey systems with all the benefits of Linux.
Re:Very cool (Score:1)
I have. My main one is an Athlon 700 w/256MB RAM and a couple 20GB HDs. I also have a PII 266 w/128MB RAM and a couple 9GB HDs.
But I used that cheap 486 once for a custom turnkey system and it was a bit slow. Immagine a cash strapped school or charity wanted to run some GUI apps but had little to no money for hardware. They could probably get several donations of computers of this caliber. And with GTK-FB, they could be worth something.
Re:Very cool (Score:1)
Re:Quick Question: (Score:1)
This article was more of a reveiw than a white paper. It *was* interesting though.
Re:Very cool (Score:1)
Basically, I'm saying that GTK-FB is cool for turnkey apps on 486s. Any disagreements with that?
Re:We'll finally get rid of the X! (Score:1)
Some moderator has a sense of humor. :)
Re:Instead of focusing on these features, GTK (Score:2)
Re:Ummmm...duh? (Score:3)
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.
Re:Ummmm...duh? (Score:1)
Too many TLA's
Re:Ummmm...duh? (Score:2)
Sounds like the frame-buffer implementation would be a lot more usable.
Re:Single process? (Score:2)
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.
Re:Low end devices... (Score:1)
-adnans (posting from a fully AA'd KDE desktop)
Re:Very cool (Score:1)
Re:Low end devices... (Score:1)
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
Re:Low end devices... (Score:1)
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
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
Re:Whats wrong with QT Embedded? (Score:2)
Second, TrollTech suggests that anyone wanting to use QT/Free on Windows should use an X server for Windows. See also: redundant; waste of resources.
Finally, TrollTech distributes the source as a pristine base, plus patches. Distributing a port to another base API as patches would be horribly inefficient, not to mention error-prone. Besides, TrollTech would have the power to deny any or all of those changes. And I have no doubt that they would.
Meanwhile, the GTK team is actively encouraging the development of Win32 and BeOS ports. In their eyes, no operating systems are more equal than others.
And that is why they will win.
We're not scare-mongering/This is really happening - Radiohead
Re:Whats wrong with QT Embedded? (Score:2)
I was a bit too liberal in my use of the word "Free". I side strongly with Open Source, myself. Something about GPL's "viral" licensing bothers me. Too close to bedtime to express it, right now. Catch me when I've been sufficiently caffeinated.
And, unfortunately, the license wars aren't going away anytime soon. Corporate interests (i.e. Apple , Sun) are still churning the waters.
I just can't get religious about computers anymore. I had that beaten out of me in my OS/2 days. ('nuff said.) I read RMS' texts, like the "Why not LGPL" link you provided, and I think to myself, "He is seeking ideological purity." Well, him and everybody else in this world.... Stallman insists that it's "Free vs. proprietary", and I just can't buy that. I try very hard not to fall into the trap of "single-bit" thinking that is so common to us geeks. Life is never that simple.
Too me, it all comes down to choice. Say I'm about to release VBFooLib to the public. I could sell binaries for $250, and charge $1500 for the source, implying that you "commie pinko scum" need not apply. Or, I could release it under LGPL, with all of the community benefits that implies. The message is simple: "I share with you, in the hopes that you will share with me." But I don't feel right mandating that. I'd rather spread the meme. In the long run, that's more powerful than the license.
And getting back to the toolkits, it's simple. QT for Windows is only avaliable as a proprietary library. For me, that trumps all other points of contention. GTK is Open. Not Free in the RMS Purity Test sense of the word, but far more suitable than QT.
BTW, GTK has far more bindings than just C. QT is locked hard into C++.
We're not scare-mongering/This is really happening - Radiohead
Re:Very cool (Score:2)
Perhaps what you mean is 'KDE is slow', in which case you could get the same speedup by keeping X, but not running KDE. Try a simple but neat-looking window manager (eg icewm) together with those apps you want to run.
Re:Very cool (Score:1)
~Sentry21~
Re:Now all we need is DirectX support ! (Score:1)
Would you settle for a mapping of Direct3D calls to Mesa's and GLX? Transgaming [transgaming.com] is working on just a beast. It's distributed as a Wine patch, and has been improving.
--
Low end devices... (Score:1)
Re:Instead of focusing on these features, GTK (Score:1)
Re:Very cool (Score:1)
Re:GIMP is well designed (Score:1)
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.
Re:Another approach (Score:2)
Something like Rasterman's EVAS may be the right step towards this, though.
Re:Whats wrong with QT Embedded? (Score:2)
Isnt this *exactly* what the GPL does? The exception in the GPL that allows it to be linked to proprietary OS components was only needed because there wasnt a Free operating system at that time. It seems to me that Qt is more free (in the RMS sense) than GTK+, since it activly encourages Free development on Free platforms while GTK+ can legally be used to develop proprietary apps on nonfree OSes. It would seem that the Qt licenses is closer to the goals of the FSF than GTK+ is. (See Why you shouldnt use the LGPL for your next library [fsf.org]) It seems to me Qt is doing the right thing while GTK is encouraging proprietary platforms (ironic, isnt it?)
Meanwhile, the GTK team is actively encouraging the development of Win32 and BeOS ports. In their eyes, no operating systems are more equal than others. And that is why they will win.
So small technicalities like Qts superior documentation [trolltech.com] or easy to use signal model, or a nice interface builder (ok, gtk has this too), and a nice, easy to use, consistant API doesnt matter? Unless you're hellbent on using C, I personally think Qt is a better choice in most cases.
And like you said.. nobody is stopping you from forking Qt and porting it to Win32. Why would you need the support of the Trolls for that? (Remember that Qt is their only product)
And i cant belive i'm replying to the obvious troll above.. the licensing wars *should* have gone away a long time ago.
-henrik
Re:Whats wrong with QT Embedded? (Score:2)
What makes the difference for me (just me, i'm not saying this applies to anyone else) is the beauty of Qt. It's a true dream to program with. That, for me, outweighs the fact that i have to pay if i want to port my programs to Windows one day. (My experiences with GTK+ are admittely rather limited - i've just written a few simple apps with it - just enough to realise that i found it a pain to work with)
BTW, GTK has far more bindings than just C. QT is locked hard into C++.
Minor nitpick - While it's true that GTK+ has more bindings than Qt, it's not true that the *only* choice for Qt is C++. There are wellmaintained and stable Python and Java bindings for Qt (works as well as native c++). C and Perl bindings exist, but i dont belive they're as good as native c++. Once gcc 3.0 comes out, with a stable c++ ABI it'll be easier to add language bindings to c++ libraries.
-henrik
Re:Whats wrong with QT Embedded? (Score:2)
1)Yes, there are C bindings for Qt. No, nobody uses them.
2)Yes, there are more language bindings for GTK than Qt.
3) No, Qt isnt C++ specific. Java, Python, XML, Perl and C bindings exist in various stages of completion.
-henrik
Re:Instead of focusing on these features, GTK (Score:1)
GIMP is well designed (Score:2)
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?)
Re:Instead of focusing on these features, GTK (Score:1)
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.
Re:Very cool (Score:1)
I haven't been complaining about bloated apps, but I could start if you'd prefer, that way you could officially be shutting me up
-------------------------------------------
I like nonsense, it wakes up the brain cells.
Re:Low end devices... (Score:2)
Re:Very cool (Score:2)
Re:Very cool (Score:2)
Re:Very cool (Score:2)
Re:Low end devices... (Score:2)
>>>>>>>>>>>>>>>>>>
Monkeys or not, BeOS users have had this "new" feature for the last year and a half. Hell, even those poor, opressed Windows users have had AA text for over half a decade now. Besides, the monkey comment was directed at those people who think that its perfectly okay that to get the best Linux DE experience, one has to use one single DE. (Otherwise it is slower, more memory intensive, and less consistant.)
As for your rundown of toolkits, what about Athena? Not everyone wants a bloated DE on their desktop, and while you may get by fine on Qt and GTK+, some of us (me) still use apps like XPlayMidi that we are perfectly happy with (and ones that have no good KDE or GNOME replacement with as good support for my AWE64) and we won't get AA in these apps. 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.) All in all, stuff like this *really* should be done at the lowest levels.
Re:Low end devices... (Score:2)
>>>>>>>>>>>
Its called a one-time license fee.
Oh, so we throw away X and just re-invent it again?
>>>>>>>>>
That's funny. If you juxtapose your Athena comments and this one, you realize that in the first, you say its perfectly fine to abandon compatibility, and in the second, you condem the idea. Besides, throwing away X would not entail reinventing it again. X is not the be-all-end-all of windowing systems; better stuff can (and has) been invented.
Please! X development might have been dormant a couple
of years ago, but man, it's going places today!
>>>>>>>
Wow! AA text!
I'm sick and tired of hearing how X is bloated and stuff.
>>>>>>
And I bet Windows users are tired of the same. That doesn't make it any less true...
My Linux X desktop with NVidia hardware is *FASTER* than anything BeOS can come up with
>>>>>>>>>>
Oh please. I was doing a quick test the other day to determine how different data set sizes affected processor intensive (matrix multiplies) code. At one point I used a small data set an an insane number of repititions. The processor was absolutely pegged because everything was being handled by the caches and my thread was using 100% of CPU time. Even then, I could open netpositive and browse reasonably comfortably (faster than most of the pre 0.8 Mozilla releases anyway.) Suffice it to say that GNOME starts flickering and jerking like hell under the same test. Not to mention the fact that KDE 2.1 (feature parity! can't use blackbox for these tests) is slower than even NT 4.0.
(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
>>>>>>>>>>>>>.
Maybe it will be pervasive by the time beta10 comes out? Listen to yourself! You're your own worst enemy!
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
>>>>>>>
Question: Who gives a damn about running a web-browser on a box half a world away. I'd rather have a 20% speed increase!
Software base. Make sure it's compatible with at least gtk+ and Qt.
>>>>>>>>>>>
Or Win32
Multi-monitor support. An X replacement would need to have this too. Good luck!
>>>>>>>>>>>
Wow! A feature first found in Windows 98! Congrats! Besides, other windowing systems (I believe photon, already have this too.)
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.
>>>>>>>>
Where did you hear this? The hooks are already in place for multiple monitor support, if you'd read the API. I'd say multiple monitor support would be much easier than multi-user, and somebody has already made a good bit of progress on that.
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.
>>>>>>>>>>>>>
Yes. X was handed down from god and all future windowing systems are desitned to be duplicates of it. Give me a break. Like I said, better stuff has already been done.
Framebuffer\GTK usefulness (Score:1)
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
Re:Very cool (Score:2)
Agreed, but I sort of assumed the biggest application of the technology was for embedded systems.
That said, I'm more interested inseeinga GTK Win32 of MacOSX port. Why? Because QT seems to be the only widget set that runs well on all these platforms, and this means those thinkign about Win32 development now and Linux as a possibility int eh future have a better time of porting when the time comes (so no more dead-slow Corel WPO2Ks to waste your money on thinking the application actually *worked* at a reasonable speed. QT rocks because of this, and GTK should too.
Re:Low end devices... (Score:2)
Here here! Its nice to know I'm not the only one who picks their apps based on quality, rather than toolkit religion. Most newcomer end users don't either. I still fail to undertstand (post licensing issues) why someone with more than the tiniest amount of grunt required to load both Qt and GTK will say a `I need a X for GNOME / KDE' when the current effort (based on whichever they've decided to rally against) works great. I use Konquror for the same reason I use Gimp - they'e the best for what they do (in my own opinion). Those who chose based on toolkit religion really fo themselves and the users they `help' a disservice.
Re:Very cool (Score:2)
Re:Of limited usefulness (Score:2)
Re:Distributed graphics (Score:1)
Try the early 90's. For instance, SGI's OpenGL and X: An Introduction [sgi.com] 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.
Re:Instead of focusing on these features, GTK (Score:2)
Re:Of limited usefulness (Score:2)
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.
Re:Very cool (Score:2)
Of course the acceleration won't be on the level of X with bitmap/texture storage and offscreen buffers etc.. but it still makes a difference - a huge one compared to the generic vga-fb..
Re:Instead of focusing on these features, GTK (Score:2)
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.
Amen to sweetness (Score:1)
Re:Whats wrong with QT Embedded? (Score:1)
Re:Quick Question: (Score:1)
Of limited usefulness (Score:2)
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.
Re: Another approach (Score:2)
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.
Another approach (Score:4)
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.
What if there are more than 254 menu items? (Score:2)
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 [gimp.org] stuff most of their interface under contextual menus, this can get in the way.
All your hallucinogen [pineight.com] are belong to us.
First move towards GUI in kernelspace? (Score:2)
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.
--
Re:Distributed graphics (Score:1)
Re:Distributed graphics (Score:1)
Re:Low end devices... (Score:1)
Re:What if there are more than 254 menu items? (Score:1)
Re:Very cool (Score:1)
Re:Whats wrong with QT Embedded? (Score:2)
Either we have a non-causal system here, or you're an idiot. My guess is the latter.
Quick Question: (Score:1)
unified sourcetrees (Score:1)
Re:Whats wrong with QT Embedded? (Score:1)
Innovation==Version number?
I remember when Microsoft released Office95 and changed the version numbers of all the applications to match. I think Excel passed from 5.0 to 7.0. This is innovation? Version numbering is not related to innovation.
Huh? (Score:1)
Games should be written to be portable in the first place by using SDL [libsdl.org] / OpenGL.
-Justin
Single process? (Score:4)
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 [trolltech.com], 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 [trolltech.com].
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
Re:Instead of focusing on these features, GTK (Score:1)
Re:Very cool (Score:1)
I'm sick of hearing people whine about Mozilla/X/whatever being bloated and slow, when they're trying to run it on a fucking 486. Christ, man... I've got an old P200 you can fucking have if it'll shut you up for a bit.
Re:Juan Epstein (Score:1)
Re:Juan Epstein (Score:2)
Distributed graphics (Score:1)
The idea at the time was something of distributed gaming.
I wonder if this new way of doing things will include such flexability ?
Re:Whats wrong with QT Embedded? (Score:1)
a) Stop offering proprietary QT and LGPL the Free one. (Which are, by the way, exactly the same in every way except license)
Whoops, there goes QT developement.
b) Allow OTHER people to use there hard work in creating this wonderful FREE (speech and beer) software to create proprietary works.
You are a selfish prig. How can I even describe it. You want someone to allow you to create proprietary software with their toolkit, using the argument that their toolkit is "proprietary" to flame it.
Re:Quick Question: (Score:1)
Games with gtk/linuxfb? (Score:1)
Re:Very cool (Score:1)
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!".
It's annoying how people mention words like "KDE" or "GNOME" in the same context as "IceWM" or "WindowMaker" when they're two entirely different things... KDE and GNOME try to be your desktops, and encompass lots of your desktop functionality, whereas IceWM and wmaker are just mere window managers. Well, with some added functionality nowadays, but still there's a certain difference.
When dropping KDE, you lose those wonderful features like functioning drag'n'drop which, unfortunately, X11 doesn't provide. Neither can wmaker or IceWM provide.
Re:Very cool (Score:1)
Re:unified sourcetrees (Score:1)
Re:Instead of focusing on these features, GTK (Score:1)
Re:Instead of focusing on these features, GTK (Score:1)
Re:Another approach (Score:1)
What's more, it seems to me that there's TREMENDOUS potential here for hardware acceleration! Think about it: you could have special hardware that automatically refreshes all the rectangles from different areas in memory, without X or Win95 or whatever even thinking about it!
It could do ALL of the clipping and such in hardware, leaving your window system or graphics toolkit with nearly 100% of the CPU to draw on the seperate rectangles by itself.
File that one under "the things I need to invent after I get as rich as Bill Gates."
[me@localhost]$ prolog
| ?- god.
! Existence error in god/0
Re:Another approach (Score:1)
Inside the rectangles, you could just use normal hardware acceleration like we have today. ALL graphics work is just drawing to an area of memory. Today that area of memory represents the screen directly. This system would have many areas of memory, each one representing a window, and the complete video image would be composited and displayed automatically by the video hardware, instead of having X manage the windows itself using precious CPU cycles.
[me@localhost]$ prolog
| ?- god.
! Existence error in god/0
Re:Instead of focusing on these features, GTK (Score:1)
Most people remember menu path, i.e. "Filters->Render->Flare" much better than a shortcut key for the same feature.
Re:Instead of focusing on these features, GTK (Score:1)
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.
Re:Instead of focusing on these features, GTK (Score:1)
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.
Re:Instead of focusing on these features, GTK (Score:1)
Instead of focusing on these features, GTK (Score:5)
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.
Re:Very cool (Score:1)
I have used X11 on machines that ran at 1/4 the speed and memory of your machine with no problems. The slowness you are seeing is in the toolkits. Also, the XFree86 implementation of X11 is probably not optimized for small machines (why should it be?), but since it is being ported to handhelds, that is getting fixed.
Re:Very cool (Score:1)
Ummmm...duh? (Score:2)
(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?
--
Re:Whats wrong with QT Embedded? (Score:1)
Not that speed of innovation is the only (or even the most important) metric when evaluating a platform for deployment in the enterprise - sometimes it isn't. However, to ignore this matter is lazy and even dishonest.
Consider: 2.4 just came out, and 2.2 was a whole year before that. And between 2.0 and 2.2 we had over two and a half years. That's a long-ass time to wait.
In fact, simple subtraction in the last release cycle yields a rate of just 0.2/*year*. Not exactly blazing speed, all things considered. I'm sure I don't even have to mention products which far surpass this rate of innovation.
--
No we didn't. You missed the point. (Score:2)
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)).