Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
GNOME GUI

Whitepaper On GTK+ For Linux Framebuffer 99

Posted by CmdrTaco from the isn't-that-special dept.
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!
This discussion has been archived. No new comments can be posted.

Whitepaper on GTK+ for Linux Framebuffer More

Whitepaper on GTK+ for Linux Framebuffer

Comments Filter:

  • Whats wrong with QT Embedded? (Score:1)

    by Anonymous Coward
    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 ;)

  • the sad thing... (Score:1)

    by Anonymous Coward
    blackbox under X will still run faster & with a smaller footprint (pun intended).

  • Re:Whats wrong with QT Embedded? (Score:1)

    by Anonymous Coward
    Whats wrong with QT Embedded?

    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)

    by Anonymous Coward
    There is one. It's called "Insightful".

  • To Go Offtopic, But To Talk To GNOME. (Score:1)

    by Anonymous Coward
    What do people think of Nautilus? I have been reading GNOTICES [gnome.org] very closely and it seems many people hate Nautilus and don't want to see it go into GNOME! What will happen?

  • Re:Very cool (Score:2)

    by Anonymous Coward
    "X is just plain glacial on it, especially with KDE. "

    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.
  • > Or you could just stop being a cheap bastard and get a real computer.

    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.
  • It did run faster before I put KDE on it, but FVWM95 (the default in Red Hat 4.1, which the thing still has on it), is so hideous I never ever wanted to look at it again! And the video card is not accelerated anyway, so I do think this will be faster.
  • 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.
  • No arguments from me. I do think KDE was the best overall desktop for the people I was targetting with that particular box, but they probably wouldn't have *needed* a desktop, so skipping X entirely would have been nice.

    Basically, I'm saying that GTK-FB is cool for turnkey apps on 486s. Any disagreements with that? :-)
  • (Score: 1, Insightful)

    Some moderator has a sense of humor. :)

  • it doesn't work because focus doesn't seem to shift after the second keystroke
    I've noticed the same problems all over the place in Gnome -- the shortcuts are useless when focus wanders from place to place in unpredictable and usually unhelpful ways. And then shortcuts work only when focus is in the right place. It's very frustrating, and seems like it shouldn't be such a big deal to do right.

  • Re:Ummmm...duh? (Score:3)

    by Ian Bicking ( 980 ) <ianb.colorstudy@com> on Saturday March 17, 2001 @09:07PM (#357364) Homepage
    GGI isn't actually a hardware interface. It's a userspace library that abstracts the hardware some (similar to Xlib in some ways). It can run ontop of several different actual display devices -- KGI (primarily Linux -- though I heard that FreeBSD was considering using it more mainstream), X, or framebuffer.

    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.
  • Let's see:
    • 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)
  • Yeah, now we only need Photon to be as pervasive as X. (Hint: ain't gonna happen)
  • 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
  • Monkeys or not, BeOS users have had this "new" feature for the last year and a half

    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 :) Athena was developed as a "sample X toolkit". I would guess the last time something radically changed in Athena was perhaps in X11R6.1 or earlier. Adding AA to Athena might be a weekend project for someone sufficiently intimate with it but seeing as it hasn't happened yet the demand must not be there. Keithp hacked the twm sources for AA, but he opted to not release the modifications. Perhaps the code is just too obscure for him to even bother cleaning it up for a release. The same goes for Athena probably.

    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 :)
  • QT is Free by the letter of the law, but not the spirit.
    • TrollTech says that they want to support the development of Free software on Free operating systems. This is why there is no GPL/QPL version of QT for Windows. Yet TrollTech appears to be willing to "tolerate" development of Free software on proprietary unix variants, like Solaris, AIX, or HP/UX, as long as they use X.
    • I can hear some muttering in the peanut gallery: "Why not port the Free X version of QT to Windows?" Simple. It's poisoned. First of all, QT for Windows already exists. TrollTech chooses not to license it for Free/Open Source software for Windows.
      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.
    Bottom line: TrollTech is acting out of spite, and picking sides. They're on some holy crusade to rid the world of the Redmond Menace, and they don't care how many innocent developers and users of Free software for Windows get caught under the tank treads.

    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
  • After making a second pass over what I wrote, I realized that I wasn't as clear as I should have been.

    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
  • If X is glacial on your machine, the framebuffer will be just as bad and probably worse. The main cause of slow graphics in X is having an unaccelerated video card; operations like scrolling or window dragging must be done by the processor copying memory about. But the Linux framebuffer doesn't have any support at all for such acceleration (AFAIK), so it will be at least as slow. In my experience it is worse.

    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.
  • Can I trade you the P200 for a Cyrix 133?

    ~Sentry21~

  • 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.

    --

  • 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.
  • The linux fb driver has some acceleration for a few chipsets. I think the real benefit of using the fb over X, is that X uses a great deal of memory. The reason KDE crawls on a 486-100 with 16 MB of ram isn't because the video card is slow, it's because KDE (like GNOME) is a memory pig.
  • (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.
  • Bottom line: TrollTech is acting out of spite, and picking sides. They're on some holy crusade to rid the world of the Redmond Menace, and they don't care how many innocent developers and users of Free software for Windows get caught under the tank treads.

    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

  • True.. you dont have to pay to develop in GTK+ on windows. I probably went a bit too heavy on the RMS rethoric in my reply, but it was mainly to illustrate a point to Free fanatics (that the proprietary Qt is a sense freeer than the open GTK+. anyway, it's not that important..).

    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

  • Because GTKs native API is C. There are language bindings for both toolkits but their native interface is C and C++ respectivly.

    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

  • 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?)
  • 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.
  • I'll take that P200 off your hands. I just put together a new Athlon system, but my old P75 needs a drinking buddy. :-)

    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.
  • But the sad thing is that there are actually limitations in X that you don't get with "lower end devices." Yea, I know XRender does AA these days, but it will be a while before AA-text is pervasive. (Unless you're a monkey and only use the apps specific to a particular DE!)
  • You don't even need X for remote display anymore. QNX's Photon does remote display at a much higher level than X (where it belongs) and is fast AND network transparent.
  • Also, I think X had a dumb design to begin with. X is *very* low-level. While this had the benifet of allow modifyable user interfaces, it also meant that apps get stuck with tons of low-level dependencies. Funny thing, though, the Windows GUI has changed a bunch since Windows 1.0, and MS never had any X-like low-level layer.
  • If all I cared that much about pervasiveness, I'd still be using Windows ;)
  • I'd say pervasive AA-text will be reality in 6 months time.
    >>>>>>>>>>>>>>>>>>
    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.
  • 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...
    >>>>>>>>>>>
    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.
  • 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 :)
  • Or you could just stop being a cheap bastard and get a real computer

    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.
  • Unless you're a monkey and only use the apps specific to a particular DE

    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.
  • And apparently sucks for Win32 development for a veriety of reasons according to just about everybody I've met that used it....yes, that one.
  • Co-routines. =)

  • 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.

  • 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.
  • There are several accelerated framebuffer drivers! tdfxfb comes to mind first(because I have two cards that run with that).

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

  • 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.
  • Hum, there's not such thing as a "corporations' fundamental right to make money". There is now law or constitution that gives this "right".
  • I've been wondering the same thing. Why can't they be black or green papers?
  • From the article:
    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.

  • The Amiga came close to having the right hardware. It had 16 (I think, it's been years) sprites of arbitrary height, but limited width. If the sprite width had been arbitrary too, the sprite engine could have been used for windowing.

    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)

    by Animats ( 122034 ) on Saturday March 17, 2001 @02:06PM (#357410) Homepage
    Maybe it should work like this:
    • Each window appears as a framebuffer device. Applications can either write the framebuffer directly, or use OpenGL on it.
    • The front window runs with top priority. Application writes to it take effect immediately. It may be a mapping of display memory if the hardware is suitable.
    • All other windows are really offscreen bitmaps. Applications write to them, and the window manager copies them to the screen when they change. Updates can be a second or two behind. All clipping is done during this copying.
    • Applications don't have to worry about window clipping, damage, or redraw. Drawing, widgets, etc. are part of the application, not the window system. All the window system knows about is rectangular bitmaps.

    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 [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.
  • Perhaps I lack some knowledge on the subject, but it appears to me that this will be the first move towards a gui subsystem in kernelspace, thus that the framebuffer as it is now will be extended with a windowing subsystem that is then controlled by a higher layer in userland.

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

  • You were using GLX I believe. It's relatively new (relative to X that is) (I can't remember how long its been around). Anyway, X couldn't always do that.

  • SGI came up with GLX, but I don't think it was that long ago. I'm thinking it was a few years ago.
  • Well, I believe that Maple uses Motif and I have to use that from time to time. xmaple is very ugly. Maybe, just maybe, there will be a Gnome interface for Maple.
  • Show me ANY program on ANY os that can have more than 254 hot keys.
  • You mean GTK+ on Win32 like offered here [user.sgic.fi] which is linked from the GTK+ webpage [gtk.org]?
  • 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
    http://www.trolltech.com/products/download/freelic ense/qtfree-dl-emb.html [trolltech.com]

    Either we have a non-causal system here, or you're an idiot. My guess is the latter.

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

  • 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.

  • 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 [libsdl.org] / OpenGL.

    -Justin

  • Single process? (Score:4)

    by infiniti99 ( 219973 ) <justin@affinix.com> on Saturday March 17, 2001 @01:28PM (#357423) Homepage
    Of course GtkFB has limitations too. 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. This means you can't use processes to separate and protect different parts of the system from each other. It also makes it harder to design larger systems.

    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
  • 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.
  • Or you could just stop being a cheap bastard and get a real computer.

    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.

  • Why don't YOU go back to drinking varnish, raping sheep, and watching the WWF in your trailer, moron.
  • Yeah, asshole. I just swam across the Rio Grande so I could secretly run your banking and entertainment industries.
  • 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 ?
  • QT is Free Software, you incompetant ninny. QT is THE BEST graphical toolkit for UNIX PERIOD. So what if they want the ability to make money from it? The only "freedom" they are denying you by GPL'ing it is the ability to make proprietary software. So you're saying, basically, they should:
    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.

  • Traditionally in the computer industry a White Paper is a high-medium level technical document put out by the marketing department. It generally isn't specifications or the full documentation.
  • 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?

  • 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.

  • Yea loosing hardware acceleration will give you a huge speed boost.
  • Gtk 2.0 will do this
  • 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?
  • Yes! I've often wondered why window systems didn't work like this.

    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
  • if you are just drawing to an area of memory (whether on the video card or in main memory), how does the acceleration work?

    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
  • 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.

  • Instead of focusing on these features, GTK (Score:5)

    by Bob Dobbz ( 321950 ) on Saturday March 17, 2001 @10:48AM (#357443) Homepage
    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.
  • X is just plain glacial on it, especially with KDE.

    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.

  • No, not at all. There are a number of X applications that don't use any toolkit. And there are a number of lightweight toolkits out there.
  • Why not just port GTK to GGI [ggi-project.org]*. 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?
    --
  • On a related note, I really like Linux, but it just isn't innovated fast enough in my experience.

    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.

    --

  • X is here to stay and we'd be stupid to get rid of it. This project uses the Linux frame buffer, which compared to X, is VERY slow (offers no accelleration (yet) for either 2D or 3D graphics). X is also an industry standard.

    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)).

Slashdot Top Deals

The best defense against logic is ignorance.

Close