Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
GNOME GUI

GTK+ without X! 191

Posted by CmdrTaco from the now-thats-a-cool-hack dept.
Rayban writes: "Just noticed on news.gnome.org that the Linux framebuffer support for Gtk+ is now in CVS. This means that you can now write a quick Gnome app that doesn't require X at all! Imagine a Gtk+-based distro installation that can run solely off the framebuffer! No more VESA hack and a significant disk space savings - maybe even a Gtk+-based bootloader? The screenshots are here, here and here." Obviously the screenshots aren't very special, but I'm having no problem thinking of interesting, useful tasks for this.
This discussion has been archived. No new comments can be posted.

GTK+ without X! More

GTK+ without X!

Comments Filter:
  • 1) You can't say that Gtk was written to build market share quickly. Gtk was written as a toolkit for GIMP.

    2) The reason that it is interfaceable with a number of languages, is because of how close it is to assembly language. Since all languages have to be "interfaceable" with assembly anyway, making them interfaceable with C is fairly trivial

    3) I have seen other systems. My experience isn't overwhelming, but I've used Java, Delphi, and Gtk/GNOME. I liked Gtk/GNOME the best.
  • Am I the only one familiar with abstraction?

    Perhaps, but that's not the point.

    Things like GTK and QT help lever programs away from the X server. Change just those and all the layers above will not notice the difference.

    Not all X applications use GTK or QT, or even toolkit libraries at all! Any "X-killer" will have to accept connections from X clients. So it will have to know the X Protocol [x.org], in addition to any new "gee-whiz" features the "X-killer" has.

  • GTK+ replacing SvgaLib (Score:5)

    by Felinoid ( 16872 ) on Friday January 05, 2001 @03:34AM (#528727) Homepage Journal
    This would be a long overdue replacement to Svga-lib.
    The one (and only) virus for Linux was made posable in part becouse of svga-libs need for super user access... (and users swapping binarys instead of source code)

    The other problem with svga-lib is it's just an interface into existing svga cards... This is useless on platforms that don't use the obsolet video chipset...

    But console graphics are the key to making linux games run faster... X11 uses a lot of memory and runs slow.. it has support for stuff that games don't need.. Window managers have stuff games don't need.. Strip all that away and the computer is many times faster..

    Something like GTK+ would use your PC 2D rendering card directly instead of using it's internal VGA emulation.. It would allow you to run with less memory and give more speed to your games..

    Also GTK+ has the added benifit of being GTK.. It would be pritty easy to port GTK code to GTK plus (and visa versa).. It should work equally well the Mac as it dose on the PC.....

    While svga-lib dosn't have that requirement to give your games superuser access.. it's still long overdue for a replacment...
  • Well it could be done, but there are two problems,
    1. X is a standard. There are alot of programs written for it. Many people are used to it.
    2. Their is not GUI, to my knowledge at least, that implements the client/server model the way X does. No gui offers seemless app running across a network. Now many of 31337 h4X0rz that read slashdot would be perfectly happy if such a GUI had a terminal emulator to run ssh from, another portion of the slashdot community wants to be abe to check their mail using netscape from any computer that runs X. This is perhaps a bad example, but I'mn sure others can think of better, and if not then perhaps this GTK frame buffer thing will take over
  • i really get a bit frightened, even though i know gtk/gdk was started on linux and due to that got some linux-specific stuff even today, this Framebuffer-thing i evil towards the one of us that uses one of the different BSD-flavors. thec day they tell me i can use it on my bsd-box without starting x, then it will be a progress...

  • Re:GGI, SDL, Qt (Score:3)

    by TeknoDragon ( 17295 ) on Friday January 05, 2001 @11:57AM (#528730) Journal
    uh, no... SDL has no graphical widget set (at least no good one)

    presumedly GTK+ in combination with GGI or SDL (as the article says "the linux-fb port of GTK+") would just put the GTK widgets on your framebuffer...

    actually, this something I was looking for a while ago (SDL + GTK = a platform independant widget set/window manager)

  • Berlin (Score:1)

    by obi ( 118631 )
    There are a lot of misconceptions about Berlin.

    First, one should realize that it overlaps with more than just the X server.

    Berlin is different in that, unlike X, it doesn't communicate between client-app and the server by pushing pixels around. It's the responsability of the server to create a decent (looking) ui, based on the calls the app makes. The fact that those calls are made using CORBA, means they're network, and language independent (perl anyone?).

    Using corba shouldn't be scary, in fact, Berlin is much lighter on bandwith in the case of remote display.

    A Berlin app can choose the level of abstraction it needs... Some apps might choose/need to draw low level primitives, while others would want to be able to position widgets themselves, while even others just don't need/want to occupy themselves with how something might look, and just tell the server a specific "task", and let it handle it. If you want to get even higher than that, you should take a look here:
    http://www.bucksch.com/1/projects/berlin/OOUI/

    Why all these levels? Well, the higher level you go, the more freedom you give the server to implement a certain function in a particular way. For instance, a color picker might be almost unnecessary on a palm, and I can't think of better use of a 3d environment than mapping a 2D ui on a texture and displaying it in 3D. As i said it's up to the server (or one of its plugins)

    Portability to totally different platforms doesn't always make sense; for instance, it wouldn't make sense to try to force 3d apps/models/vertices and the like in a palm; So if an app wants to use 3d models, it has to create them using a lower level 3d "kit" (which is just another server plugin). That way, the app writer can choose the trade-off.

    Other things that I find important are: the resolution-independence (why are >1600x1200 or 640x480 displays almost unusable without heavy adjustments?); the fact that the policy is defined on the server (am i the only one that thinks "meta-theming" - making theme "packages" for different toolkits that go together - is a kludge)

    Where does Gtk+ come in? Right now, Berlin sits on top of lower level graphic libraries (libart+ggi, opengl, others are possible). recently it's been possible to use GGI inside Berlin too... so that makes it: GGI on Berlin, on GGI on FB/X/glide/whatever (btw libGGI 2.0 will be out soon). Knowing this there would be 2 different ways of porting GTK+:

    1) port GTK+ to GGI - additional benefits are that you get a whole lot of GGI "targets" gtk+ would work on. From what i hear GDK is pretty easy to port.

    2) intercept the gtk widget creation calls and map them to the Berlin widgetkit. Advantage: gtk apps would blend in pretty well with real berlin apps, and have all berlin's advantages of being higher level and pixel independent. Disadvantage: i would think it would be _alot_ harder to do.

    I guess the difference between the two is a bit (tiny bit) similar to the difference between Wine (api reimplementation) and running plex86 to run windows itself.

    Now if Berlin's so great, why hasn't it taken off yet. Unfortunately, the best doesn't always win. DPS for X isn't there yet (dps.sourceforge.net), despite the fact that it's "proven to be good" by for instance MacOSX. (okay it's not entirely thesame but you get my drift)

    A major problem with Berlin is that to explain the advantages, you have to write as much as i did just now. Once you know the advantages, it seems obvious that this is the way to go, but as i said, even the people who are interested don't always understand the advantages about it immediately. That means that few developers actually get into it, meaning slow progress and no critical mass yet.

    Otoh, the fact that it has gone on for all these years, even when new good-looking ui tech came out, and that the developers still aren't giving up on it at all, proves that a) they're fools or b) they're onto something.

    I definately don't think these people are fools. I believe it's one of the few OSS projects that is actually really innovating.

  • small typo:

    For instance, a color picker might be almost unnecessary on a palm, and I can't think of better use of a 3d environment than mapping a 2D ui on a texture and displaying it in 3D. As i said it's up to the server (or one of its plugins)

    should be "...

    for instance, a color picker might be almost unnecessary on a palm, and should be replaced on the server by something simpler, and I CAN think of better use of a 3d environment than mapping a 2D ui on a texture and displaying it in 3D.

    ..."
  • You need write permission to /dev/fbsomething.

    There is a PAM module that some Linux distributions ship with and that provides chowning files to a user upon login of that user at the console.

    In the worst case, you could create a `framebuffer' group, give the group r/w permissions on the framebuffer device-files, and put some users into that group.
  • Now THIS is a good idea! Goddamn installing mandrake takes me like 2-3 hours! Graphical installers and all, why not have a little game of tetris (or for mandrake, a "short" game of freeciv) running at the side?
  • I think this is one more example of false ideas that somewhat became mainstream and keep being repeated in a drone fashion.

    Thank you! I'm typing this running X over my wireless network, I love X's remote capabilities. Furthermore, Xfree is certainly going in the right direction and isn't as bloated as is made out, anyone that hasn't really investigated xfree's efforts and is stating such anti X feelings certainly hasn't seen the progress thats been made.

    For sure, X could be better in the speed department but what couldn't? It will always have to do things that a games console for example doesn't have to do (e.g. remote displays) but it's certainly NOT painful to use.

  • you will experience deja vu.

    --

  • the problem with UNIX is the languages (Score:3)

    by q000921 ( 235076 ) on Friday January 05, 2001 @06:59AM (#528737)
    Component reuse in UNIX is hard because of the primary programming languages used in UNIX: C and C++. What is missing from those languages is:
    • Full support for reflection: something that lets you take an arbitrary object, inspect its fields, invoke methods on it, etc.
    • Fault isolation: if some library or dynamically loaded module contains a serious error, there is nothing the application program can do to recover or even detect the problem reliably. That means that every extra component you add to your program has the potential for disaster, and people are going to be as conservative as they can be for reuse.
    • Automatic memory management: automatic memory management is important for fault isolation, but it is also important in itself for reuse. Without automatic memory management, the APIs to many libraries become much more complicated, and programmers have to spend a lot more time debugging and testing.

    Of course, you can simulate all that stuff in C or C++: systems like COM try to address some of those issues. The problem is that if it isn't built into the language and runtime, everybody does it differently, the compiler can't help you, and you still don't get fault isolation.

    Miguel could have done a lot for "Making UNIX Not Suck" if he had chosen a better language and runtime. His choice represents merely another pragmatic compromise in a long string of pragmatic compromises made in the industry. Gnome is well done, it works well, it has lots of functionality, but fundamentally, it merely "sucks less" and doesn't avoid the problems that are at the root of the problems with most UNIX and Windows software.

    Of course, if Miguel had chosen differently, Gnome would not have become nearly as successful, since it mostly depends on the willingness of others to volunteer. Some other C/C++-based environment would have caught on. Ultimately, the "sucky" state of UNIX and Windows software is the result of the choices we all make day-to-day. Maybe we can make it a millenial resolution to use other languages and runtimes more: Java, Oberon, OCAML, Modula-3, C#, Eiffel, Python, Scheme, etc. Given that Gtk does bind pretty well to most of those, we can even stick with the Gtk toolkit.

  • you will experience deja vu.



    --
  • (Consider this circa 1993 in terms of how 'old Unix' businesses and users felt)

    You know, I used to follow Linux. I was hopeful that it might provide the replacement for UNIX within my professional lifetime. I have since given up hope.

    Linux development is moving at a snail's place. They don't have just a whole lot of people working on it, and I'm not sure they have *anyone* working on it full time. While the attempt is certainly noble, I don't think it's going anywhere.

    More importantly, even if they manage to finish the project and come out with a reasonable, clean replacement for commercial UNIX, how are they going to persuade the industry to use it? There is a ridiculous amount of binary code written for SunOS, AIX, Ultrix, etc. To make any inroads they are going to have to have backwards compatibility with them, in which case they've moved to a new house, but carried the old baggage with them.

    I certainly do not believe the commercial Unix vendors are going to embrace such a new development. Would the Linux supporters be confident enough to break compatibility and go their own way? I don't see the balance of power between open / commercial shifting that quickly. And so far I have seen zero support of Linux from any commercial entities (even big companies like IBM).

    If Linux is used, I expect it will be in "fringe" applications first, not mainline workstations. Particularly, embedded applications might pick it up. They have a much smaller pool of software to tote around, and would probably be happy to have a kernel system smaller, and more open, than commercial UNIX.

    To bring this to a close, as "cool" as Linux may sound, the software is far from complete, is advancing slowly, and will face serious obstacles once it *is* complete. I, personally, have given up hope on Linux. I do not think it will replace UNIX. My hopes lie instead with Solaris. There is much that can be done in the way of gradually extending Solaris, and deprecating old features. Over time, they can drift Solaris towards a cleaner system, relegating cruft to libraries which get loaded less and less often. This is less inspiring, but probably more feasible.

    Three reorganizations are worth one revolution.

    The lesson is: have patience, and contribute -- the rest will follow in time.
    --
  • I think this is great. It will be quite useful in a number of "specialty" applications, like boot loaders, some embedded systems, etc.

    OTOH, I think it won't replace X11. I think the additional functionality it provides (remote display, integration of different toolkits, separate window management, asynchronous graphics) greatly outweigh any perceived or actual overhead or limitations of the X11 system.

  • Yes, but frame buffer gives you less then minimum of what your graphics card have. Stuff like hardware drawing acceleration, hardware cursor, video, 3D, and other features are not supported at all..

    So yes, it's nice for a simple graphics appplication, but nothing more then that...
  • To make any inroads they are going to have to have backwards compatibility with X

    Berlin itself doesn't need backwards compatibility with X, it just needs someone to write an X server for Berlin. I display X applications on my MS Windows machines because I have an X server for Windows, this doesn't mean Windows has any kind of "backwards compatibility" with X. Windows has no knowledge of X. Berlin doesn't need any knowledge of X, just an X server that does.
  • GTK+ looks to me to be a console graphics libary (as GTK is an X11 interface libary)

    Actually, "GTK+" is the correct name for what you're calling "GTK". GTK+ lays atop GDK. The "+" is documented in the GTK+ FAQ:


    1.4 What is the + in GTK+?

    Peter Mattis informed the gtk mailing list that:
    "I originally wrote gtk which included the three libraries, libglib, libgdk and libgtk. It featured a flat widget hierarchy. That is, you couldn't derive a new widget from an existing one. And it contained a more standard callback mechanism instead of the signal mechanism now present in gtk+. The + was added to distinguish between the original version of gtk and the new version. You can think of it as being an enhancement to the original gtk that adds object oriented features."

  • GGI? (Score:1)

    by Anonymous Coward
    Why are Qt and GTK going directly to the framebuffer?

    GGI [ggi-project.org] - the general graphics interface is a graphics API that supports multiple targets, including X, the framebuffer, ascii art rendering, and recently, an experimental MS windows DirectX target. Using a wrapper library would seem like a better idea because of the portability. There is an old GGI demo disk lying around somewhere showing that you can fit Linux+GGI in 1.4 megs).

  • wow, what a flamefest...

    cduffy is right... and the only reason that widget sets CAN'T and AREN'T used it that THERE HAVE BEEN NO GOOD FRAMEBUFFER WIDGET SETS UNTIL NOW!!!

    a framebuffer widget set __**IS**__ portable that's what my whole argument was!
  • GTK+ looks to me to be a console graphics libary (as GTK is an X11 interface libary)
    EyeCandy is the effort of the application...
  • This is just great. It won't reduce the bloat that much. But this is pretty cool for platform with no X, or for ports (say BeOS, or Mac OS X).

    In any case, reducing dependancies is nice.

    (Extra bonus. As a X hater, this is good news [I don't really hate X per-see, but I hate the window manager concept, mostly because there are so much to choose from, and none correctly working out of the box, IMHO])

    Cheers,

    --fred
  • I totally agree!

    If anything else is f*cked up in some way, the text console is my friend!

    Also, what if the grafixlibs suddently are corrupt on boot, then what? The console is supported by the lowest lowlevel grafixmode, thus it is almost failsafe.

    The console as president!
  • As long as there are still 'legacy' X apps, you'll need to run X anyway

    I don't really understand why people complain about X. X is nice, extensible, flexible and reasonably fast (both 2D and 3D wise with the event of Xfree 4.x)
    Don't get me wrong, I'd love to see the architectural disaster that is X go

    What architectural disaster? Able to run remote apps, use more than one monitor, infrastructure for 3D and 2D, works on nearly a zillon platforms (last time I looked windows was x86 only, so was BeOS, Others comes to mind easily)

    It's not trivial to design an implement an system as large as X, but I for one think that the developers are doing just fine.

    Hmm, getting offtopic here.

    Gtk+ for framebuffer devices has it's place, but only in lowmemory situations and/or before the
    system is really up'n'running (where I think another infrastructure should take over, X for example)

  • Would this make it possible to replace X with a lightweight GUI similar to the GUI on the QNX one floppy distribution?

    Yes, but X doesn't take that much space actually. It's GTK and GNOME that take up all your RAM (and HD).

  • uh, no... SDL has no graphical widget set (at least no good one
    >>>>>>>>>>>>>
    Uh, games don't use graphical widgets!

  • Re:Uhmm (Score:1)

    by cduffy ( 652 )
    The kernel fb is (nearly or entirely) unaccelarated. It's certainly much slower than, say, an accelerated X server using DGA and friends.
  • Its not an fb driver performance issue, it is the fact that fb is just that, the frame buffer. There are some drivers that implement hardware acceleration for the frame buffer, but others just give you memory area to write to.

    X doesn't use the fb, (well, some versions do, but not normally) but uses user-mode drivers that use hardware acceleration.

    Grub IS in the same position as Lilo. When the PC boots, it first loads the MBR. (In this case, part of GRUB.) Then, GRUB loads the rest of itself and displays the boot menu. Finally, it does stuff like switch into protected mode, etc, and allows you to load a kernel. The fb device isn't actually available until the kernel is loaded, and by then, GRUB is already gone. The only way to do GTK in GRUB would be to compile glib, GTK+, and the kernel fb code into the bootloader. (A scary proposition, since GRUB itself, at 37K is horrendously bloated for a boot-loader.)
  • I use the aty128fb driver for my ATI Rage 128. It's significantly faster than the stock VESA buffer from what I can tell, but it's still pretty slow and laggy.
  • You understated it. X runs perfectly well on my pentium 60, as well as my Multia, the ass-slowest Alpha machine you can buy. X is even acceptable on my AT&T Safari laptop (386sx-20), after the swapping is over. I don't know why people complain about X being bloated/slow/whatever. It certainly runs on hadrware I wouldn't dare to load Windows 2000 on.
  • Why would you want to do that?

    I *like* to have different framebuffer-based apps on different consoles.
  • That's what VNC is for.
  • Berlin itself doesn't need backwards compatibility with X, it just needs someone to write an X server for Berlin.

    I think this has already been done. If Berlin is still planning to use the GGI library, one could just run XGGI.

  • ...LinuxBIOS [lanl.gov] or some other embedded Linux kernel.
    Tetris on drugs, NES music, and GNOME vs. KDE Bingo [pineight.com].
  • Would this make it possible to replace X with a lightweight GUI similar to the GUI on the QNX one floppy distribution?
  • Frank Lloyd Wright said "form follows function". So he, generally regarded as an expert in design, would agree with you when you say "Functionality should come before the looks."

    However, this does not mean that graphic design is irrelevant. It is very satisfying to look at good design. Making conscious choices with regards to design can be very challenging and is as much as a task / artform as programming itself. This is why an entire design industry exists.

    This is terribly off topic, but the lack of what I consider good design is one of the things that turned me off of linux after using it ~2 years. Then again, on the converse side of the monetary unit, BeOS has what I consider good design, but not all the functionality in a web browser that I desire..

  • This is ripe for PDA development, of course. And if AbiWord, Gnumeric and all could be run on a palm-sized unit, that'd be nothing to sneeze at. :)

  • Re:GTK (Score:1)

    by drendite ( 3 )
    Well, I believe his argument is: Why shouldn't GTK have a well designed default look (sans theme)?
  • Now we just need Gtk+ to run over VNC as a native network hextile protocol and all of those network devices could just have their pretty interfaces exposed to any viewing device on the network.

    So could I surf on my Windows desktop at work looking at vncviewer running on my Linux desktop at home running on top of Gtk+/VNC displayed on my TV while sitting on my couch? (In the house that jack built)
  • I agree that the current default GTK+ theme is a little ugly, but you have to understand that GTK was made for the Gimp, and the Gimp was originally written in Motif, so the person in charge of how it looks was probably shooting for something that resembled motif.

    Worry not, the new default GTK+ theme will look better, and be more customizable (IE up/down arrows on both sides of a scrollbar w/out using a hack).


    He who knows not, and knows he knows not is a wise man
  • 1) Everything is a pragmatic compromise. Really. The whole point of computers is pragmatism. Would you rather them be not pragmatic?

    2) The great thing about C is that it is interfaceable with a number of languages. I think that other languages are _great_ for application programming, but library programming is best done in C. Maybe the panel should be written in another language. The windowmanager already is (scheme-like if you use SawFish). With C, the application programmer gets to pick his choice of languages. With others, it is much harder.

    3) It would be cool for someone to make a language that used the glib object model implicitly. That would be uber-cool.

    glib/gtk is about the best-designed piece of software I've ever seen. It's wonderful, easy-to-use, and fun to program with.
  • You're still missing the point. Distros are what the users use. And no, distros should not be giving people that much choice. However, as the previous poster said, there is no such thing as too much choice. The user should never have to pick a window manager, that should be done by the distro. The should never decide that they want to use GTK on the framebuffer, the distro should not give them that option. However, saying that there is too much choice is like saying there are too many engines for cars these days. Well, you don't buy an engine, you buy a whole car, all put together. When you get in to engine shopping, you go to a mechanic, who _does_ know the details. Drivers should never pretend to be mechanics, either in driving or in software. However, the mechanics and manufacturers should have as much choice as possible.
  • Someone suggested that this could be used for playing games when booting. Good idea, but my Mandrake box takes about 30 seconds to boot. It would be more useful to be able to do something like playing GTK Tetris while your new distro is installing. Imagine the screen split in half, with blocks falling down one side and package info scrolling up the other side. Installing takes 30 mins - booting takes 30 seconds. Go think what one you'd rather play a game while waiting on.

  • Re:I'd be impressed... (Score:4)

    by Anonymous Coward on Friday January 05, 2001 @03:50AM (#528773)

    Did you really look at the screenshots [lysator.liu.se] before posting this? Take a look at the anti-aliasing of the fonts, rendering of Hebrew and Arabic characters, bi-directional text and other features. I honestly do not think that some other toolkit has been doing this for ages... (anti-aliasing yes, BiDi no)

    Another minor point: Qt/Embedded is released under the GPL (or Qt Professional Edition license), while GtkFB is released under the LGPL. This makes a big difference if you want to develop a commercial application. This difference can be better or worse, depending on your point of view.

  • joins the Embedded World... *stops playing Queen on his iPAQ and gets back to /.*

    Like someone has allready mentioned GTK != Gnome, and if my memory serves me right, Gnome still requires X in one way or another, here and there.

    But this doesn't surprise me, i've been waiting for this, with the hole, Qt Embedded, QPE, Konqueror Embedded on the iPAQ (and similar handhelds) allready released it was just a matter of time for GTK to finally (i may add) to get the code into CVS, this was allready posted on /. a couple of months ago (GTK Embedded, when the Trolls were talking about Qt Embedded) (PS, it was actually sad, i couldn't find anything on it afterwards besides the plain and simple page that was up, even a search on google turned nothing up)

    But..i doubt i'll be going for the GTK solution (yet again) as the Qt solution is alot nicer for what i plan on doing for the ALFS (Automated LinuxFromScratch) Front-end graphical installer, but that's not a bad thing, at least now i have an even bigger choice when it comes to hacking for small resources/embedded devices! Qt Embedded, GTK Embedded, Microwindows are the three that are standing out so far (well that i have seen :)

    I hope this continues, i'm going to love the next couple of months with the Trolls hiting back with something better then GTK doing the same *winks* (and vise-versa of course)

  • Re:Will GTK become Yet Another X? (Score:4)

    by Flavio ( 12072 ) on Friday January 05, 2001 @03:56AM (#528775)
    I'd love to see the architectural disaster that is X go

    Why do people keep saying that X is an architectural disaster?

    I think this is one more example of false ideas that somewhat became mainstream and keep being repeated in a drone fashion.

    Of course X isn't the most optimized application around, but I seriously don't see how it's an "architectural disaster". Most people don't remember that the whole point of X is to run applications in a network environment, even if they're used locally.

    It's fine with me if you don't use even half the functions X has to offer you, but don't call it a disaster because of that.

    Flavio
  • The GNOME team is working on exactly that - just check out Nautilus and Helix GNOME and Evolution.

    The community shouldn't have a sense of direction. We are all individuals here. Direction should only be maintained (1) with the project maintainers (not the individual developers) and (2) with the dists. They are responsible for cohesion and direction on what they work on. Why should you tell me what I should work on?

    Of course things in Linux look like copies of other things. Most innovation is incremental, not revolutionary. Revolutionary innovation is only practically realizable in incremental changes from the current place. The free software movement has only been really active for a short time, so we are coding to catch up, and then do incremental innovation from there. In the places where we didn't have 20 years worth to catch up, we are far in the lead (webserving, internet services, etc).

    If you want current innovation on the UI front, look at Eazel.

    The GNOME team has done a great job, I use GNOME/DIA/AbiWord as part of my job, and they work wonderfully. And, I'm running them all on a leftover PMac 7300. And I have the free software movement to thank for that.

  • ...esp. what with fb support getting pretty good in the newest kernel. Not that you really need anything more than LILO-ish text, but there's something cool about "select OS, click "boot" to boot" (image button with a boot on it? ;^) ). I am aware that some projects to this effect exist already, but since this is essentially straight GTK+, it makes dev all the easier.

    Actually, this would make writing a highly internationalizable boot loader a possibility, wouldn't it? Well, easier than reinventing your own multillingual wheel anyway.

    And lets not forget that now a bootloader could have tetris in it, just for kicks. :-) Just think, why bother booting the whole OS when you just need to get your Tetris fix?


    --
  • Gtk+ is a very well designed piece of software. Moving it to xyz platform is actually quite easy compared to most windowing toolkits.

    This is because of a thing called gdk. gdk is the abstraction layer that gtk+ uses to talk to a windowing system. It feels a lot like Xlib, but isn't. The most important differences are: it uses glib's more advanced data structures; it provides more robust error handling and it also permutes the XEvent system into glib/gtk's thread-safe "signal" system (not to be confused with POSIX signals).

    There are limitations, however. gdk must get its fonts from somewhere, so I suspect that this code still requires an X font server. That's not so bad, as xfs is pretty light-weight compared to the X server.

    Personally, I just wish more of the code out there would start using glib and Gnome for things like error handling, internationalization and configuration preservation. Even non-graphical programs can benefit from complying with the Gnome application standards.

  • One thing to keep in mind is that, IIRC, X11's memory usage displayed by top includes the portion of the video card's ram it's using (maybe all of it? Somebody mentioned this to me a while back and I never really dug into it.). So while this is memory the process is using, it isn't coming out of your system RAM.


    --

  • Hmm. (Score:3)

    by MartinG ( 52587 ) on Friday January 05, 2001 @04:06AM (#528796) Homepage Journal
    I am by no means an expert, but it seems there are some bad ideas floating around here.

    Firstly, this is not gtk+ becoming bloated. If it's been done in line with how gtk+ was originally written, the framebuffer support is not actually in libgtk+ but in libgdk. libgdk is a later below the widget set itself, and until now has been a fairly simple wrapper around x primitives. No doubt, gtk+ has also changed because of this but don't expect to see X specific or framebuffer specific or anything else specific code in libgtk+ itself.

    Secondly, I think the article is not correct to say you can now write a gnome app. I might be wrong, but i believe gnome requires X right now which i believe is a design mistake due to lack of orthogonality. (Note: I havent looked at gnome for a long time, so I may be wrong - apologies to gnome developers if so)

  • Thinking Too Small (Score:4)

    by gomerbud ( 117904 ) on Friday January 05, 2001 @04:10AM (#528798) Homepage
    Ah, but framebuffer GTK+ will never be as cool as Berlin [berlin-consortium.org]. If you're bragging about its ability to do anti-aliasing and other fun stuff like that, Berlin does cool alpha channel stuff, does IPC using CORBA, and it does Unicode. Its kind of like X, but it really isn't, but it's better.

    Go ahead and flame away. I'm ready for it...

  • 1. That would make things much more complicated than they already are. Each lib would have proprietary commands for each set of widgets.
    Any reason why a generic IPC-type mechanism couldn't do the trick?

    Only real problem I see is that you'd have to have your widget set installed on the machine with the X server; however, that could be worked around by falling back to a lower-level protocol (ie X as it exists currently).
  • I work for an embedded systems company currently funding some work on gtk+ (Michael Taht's "squashed-gtk", meant for display on tiny screens). I'd be unsurprised if we (or another such company) take the initiative in getting an integer patch done (any reason that such a patch couldn't be merged into the main tree? oh, compatibilty. ugh).

    Frankly, it doesn't strike me as something which would likely be too close to insurmountable (and I've poked at gtk before, though not so recently).
  • I'm not sure how you'd be making a bootloader with GTK+ -- which uses the linux framebuffer, or X.

    - - - - -

  • Uhmm (Score:2)

    by xer.xes ( 4181 )
    I think you're missing the point. GTK+ isn't providing a framebuffer, GTK+ needs a framebuffer now, like SVGA-lib. Looks like GTK+ is going to blow back some life into SVGA-lib. If you want to run non-suid-root binaries that display graphics, I suggest you check out the efforts of the GGI project.

  • LILO does not have a framebuffer (Score:3)

    by jfunk ( 33224 ) <jfunk@roadrunner.nf.net> on Friday January 05, 2001 @05:18AM (#528818) Homepage
    Until LILO has a framebuffer (my guess: never), you cannot use this in a boot loader.

    Corel made a graphical LILO replacement, which simply used video memory to draw the graphics. There is no room in the bootsector to load GTK, Qt, or GGI.

    Wow, I'm surprised. Even for Slashdot, there is a lot of misleading and incorrect information here...
  • Better yet, why not target to SDL, which supports.... X, the framebuffer, ascii art, Windows GGI, DirectX, BeOS, (OS/2, IIRC), and GGI? Plus, SDL has built-in OpenGL support, which would make writing OpenGL GTK+ widgets/wrappers much, much, easier.
  • But glib isn't really that good. I mean, does anybody but me actually read the source?

    For instance, if the system runs out of memory, an error is invoked. Now, the error handler exits with a message by default. I suppose there's some way to change this, but you had better exit, because at least some of the data structures do not check for success/failure.

    In my mind, this means it CAN NOT be used for critical server applications, and probably SHOULD NOT be used for end-user applications.

    Sure, it's nice for some things because of handy hashes, lists and so on, but it's not as well reviewed or specified as the things that Miguel de Icaza is comparing it to, like the standard C library or the POSIX API. (And to be sure, just use Perl or some other scripting language for anything that isn't a critical server application or an end-user application.)
  • What games do *you* play?

    'Cuz when I'm playing FreeCIV or gnethack, I sure as heck see widgets. For that matter, when I watch my friend playing Everquest, I see widgets there too. (They're pixmap'd and thus don't look the same, but they're widgets nonetheless).

    I suppose you could have a game without any widgets, but these are much more rare than one might think -- and it's a waste for game developers to write their own widget sets (as I've known more than a few to do, eg for XShipWars).
  • Actually, Corel's bootloader was a modified version of GRUB. Check it out sometime, it's pretty cool - although I've never been able to install it properly on any of my systems.
  • The X architecture is great in theory for remote administration, but you can't, for example, display a skinned gtk window from an app that's running remotely over a 10baseT network with acceptable performance. It should be the server that does all the drawing of widgets, the client should just run the main functionality of the app and send commands to the server to draw a widget, instead of creating a bitmap of a widget and sending it over the network.

    Notice you're talking 10baseT. That's 1.2 MB/s. I haven't run skinned GTK apps, but I occasionally run adobe acrobat and netscape navigator without any issues (it's a 100baseT, but network usage never goes as high as 1MB/s).

    And in any case, you can use compression on the link (either with SSH or with LBX (lbx is included with practically all distros out there)).

    I partially agree with you that the client should draw the stuff or at least leave that as an option.

    The problems are that:

    1. That would make things much more complicated than they already are. Each lib would have proprietary commands for each set of widgets.

    2. That forces the client to have the widget drawing library of the exact same version. That may strike you as simple, but it'd be a headache to sysadmins out there. Just imagine not being able to run some program because you don't have its library. Or worse, the library's proprietary AND commercial.

    3. The client would use more CPU and RAM than without normal bitmap drawing. This isn't much of an issue today, but at the time X was designed this was absolutely crucial.

    Flavio
  • Personally, I just wish more of the code out there would start using glib and Gnome for things like error handling, internationalization and configuration preservation. Even non-graphical programs can benefit from complying with the Gnome application standards.

    Well said. Miguel de Icaza made a similar point in his paper, Let's Make Unix Not Suck [helixcode.com] : in general, component reuse in Linux just isn't happening beyond libc and xlib, whereas this is something that IE actually does right-- it's built of a collection of reusable COM components. Much kudos should be accorded to gtk and friends for having a policy of software reuse that goes beyond the merely graphical.

    It'd probably be offtopic here to consider whether applications which don't share components with others (MdI lists Samba, Apache, NFSD, innd, sendmail, in.named, ftpd, ssh, Netscape, GhostView, XDVI, Acrobat, Mathematica, Maple, Purify, FrameMaker, and Star Office) could or should be redesigned or patched to make use of glib as well; but it's ontopic to agree with you about the benefits of glib's reusability, and indeed to add that the use of glib is IMO something that should be considered carefully if anyone's starting a new project in C.

  • This would be great for embedded systems where you need to trim the memory footprint down a little bit. For a general-purpose desktop computer, X11 is the way to go, because it's capable of running multiple toolkits, network transparency, direct rendering, and a bunch of other stuff - all at the same time.

    But what if you're building the next Tivo? An embedded Linux system, on which you control the application software which will be delivered, doesn't need that stuff. GTK+ directly to the framebuffer removes some of the guesswork (indeed, with VESA it removes nearly all of it) and would bring about a lower memory footprint and faster time-to-market, while still allowing the developers to prototype the app software on regular GTK+ running on X11.

    Kudos to the innovative GTK developers.
    --
  • This is not only good news for the menus-in-your-boot-login crowd but also for people who don't want the hassle of writing their own widget sets under the console using ncurses or some other toolkit. Single source tree - works under X using Gtk+ or under the framebuffer for those who don't want (or need) X to run. Nice.

    One question though - what about the GDK functions? Will those be transparently wrapped?

  • muLinux was able to cram X on a floppy.

    X Window System VGA-16 server, with fvwm95, Afterstep , wm2 Window Managers, + xfm File and Applications Manager and Chimera WWW Browser for X (1722k)

    http://mulinux.nevalabs.org/ [nevalabs.org]

  • Berlin: not going anywhere fast. (Score:5)

    by slothbait ( 2922 ) on Friday January 05, 2001 @05:29AM (#528843)
    You know, I used to follow Berlin. I was hopeful that it might provide the replacement for X within my professional lifetime. I have since given up hope.

    Berlin development is moving at a snail's place. They don't have just a whole lot of people working on it, and I'm not sure they have *anyone* working on it full time. While the attempt is certainly noble, I don't think it's going anywhere.

    More importantly, even if they manage to finish the project and come out with a reasonable, clean replacement for X, how are they going to persuade the industry to use it? There is a ridiculous amount of code written for X. To make any inroads they are going to have to have backwards compatibility with X, in which case they've moved to a new house, but carried the old baggage with them.

    I certainly do not believe the commercial Unix vendors are going to embrace such a new development. Would the free Unix distros be confident enough to break compatibility and go their own way? I don't see the balance of power between open / commercial shifting that quickly. And so far I have seen zero support of Berlin from any commercial entities (even companies like Red Hat).

    If Berlin is used, I expect it will be in "fringe" applications first, not mainline workstations. Particularly, embedded applications might pick it up. They have a much smaller pool of software to tote around, and would probably be happy to have a graphics system nicer, and hopefully smaller, than X.

    To bring this to a close, as "cool" as Berlin's feature sheet may sound, the software is far from complete, is advancing slowly, and will face serious obstacles once it *is* complete. I, personally, have given up hope on Berlin. I do not think it will replace X. My hopes lie instead with XFree86. There is much that can be done in the way of gradually extending X, and deprecating old features. Over time, they can drift X towards a cleaner system, relegating cruft to libraries which get loaded less and less often. This is less inspiring, but probably more feasible.

    Three reorganizations are worth one revolution.

    --Lenny

  • Re:Thinking Too Small (Score:4)

    by Gorgonzola ( 24839 ) on Friday January 05, 2001 @04:58AM (#528845) Homepage
    Actually, as soon as someone writes a Berlin version of GDK, you will get a Berlin GTK+. GTK+ is not a competitor to Berlin, but it could complement it. Berlin would benefit big time from the capabality to run all those GTK+ applications. If you really think Berlin is so cool, write a GDK implementation for it and the masses will follow.
  • Caldera (at least 2.3 used to) lets you play tetris while is installing the files.

    --

  • Not very interesting for non-pda employment (Score:5)

    by thorsen ( 9515 ) on Friday January 05, 2001 @05:36AM (#528848) Homepage
    There's one very common misunderstanding about the framebuffer: Speed. People seems to think that fb is fast because it talks directly to the hardware. It is not. In fact it is so painfully slow that anything resembling normal X resolutions and colordepths will be a horrible experience. Just try running an actual graphical application on fb, it will feel like java on a P166.

    Where it could get interesting is if this would change for the better. There's no reason that the kernel drivers for fb couldn't be faster than they are right now. One problem would of course be that good drivers will have to be written for both X and the kernel where presently the kernel drivers are extremely basic. But when you start wanting 3D drivers, network transparency etc. you'll end up with something just as big as X anyway. (And having X or something of it's size in the kernel seems like a very bad idea.) The reasons for replacing X has nothing to do with speed or memory use.

    When Qt embedded was GPL'ed and later when Konqueror embedded was released, there was a LOT of people talking about running KDE on fb. The speed problem alone makes this unusable for now, but even if this could be solved, KDE classes use quite a lot of X calls to perform as fast as possible. While it might or might not be as big a problem with Gnome, you will still have the situation where you now have two different underlying implementations which is much more awkward than just using X natively.

    One place this will definately NOT benefit is LILO. The framebuffer is implemented by the kernel and LILO is used to load the kernel. This means that there is no way LILO can ever use the kernel's fb implementation. At least not unless someone finishes the kernel-in-bios hack but that's someway off in the future yet.
  • It is nice that gdk has been ported to fb, it will help get all the X depndencies out of it (which made the Windows port so hard). But gtk+ is not really ready for embedded systems as all the widgets are based on floating point. Arm systems (for example) have to emulate this in software so it is going to be really slow unless we write a whole new set of integeer based widgets...

  • No overhead savings (Score:3)

    by kentheman ( 24620 ) on Friday January 05, 2001 @03:04AM (#528854) Homepage
    Most of the memory overhead in X is due to pixmaps (allocated by applications, not by X self), and memory maps ... So X isn't as bloated as you think, when looking at top(1).

    X runs even on the Compaq iPAQ, so that proves that X isn't bloated...

  • Also GTK+ has the added benifit of being GTK.. It would be pritty easy to port GTK code to GTK plus (and visa versa)


    Ummmm, my understanding is that there really isn't a "GTK" (the original Gimp toolkit, which really isn't around any more). "GTK+" refers to the current Gimp toolkit that is in use by Gimp, Gnome, etc. It is based on the C language.


    "GTK--" is the version with C++ bindings, if that is what you meant. When people say "GTK" these days, they most likely mean "GTK+".

  • \subject... just FYI.

    --
  • They're not standard GUI widgets. They are custom made in game widgets. They don't use the system GUI code (like GTK+ widgets) but draw their own directly onto the screen. CivCTP has widgets, for example, and it uses SDL. Thus, it must be drawing its own, non? Same thing for Everquest. The widgets aren't just pixmap'd (something that Win32 doesn't allow you to do) but are widgets that use the in-game event handling and drawing code.
  • Why? GDK IS that plugin system!
  • To me, the fact that proves X is bloated is the 20MB of binaries I need to download to run it. I'm sorry, but when BeOS and QNX are doing full scale GUIs (toolkits and all) in a couple of MB, 20, or even 10MB is seriously bloated.
  • That's right, and it's a waste.

    I'd much rather see game designers using standardized widget sets where possible. (Incidentally, some game-targeted pixmap-capable widget sets are available for SDL, the windows port inclusive).

    I never said games used /standard/ widget sets, just that they use widget sets. That they don't frequently use standard ones is unfortunate, as it's Yet Another Task that game programmers have to do. (And there /are/ still games like {Free,}Civ where standard widget sets are used... your blanket "games don't use widget sets" is wrong even if reinterpreted to refer only to standard widget sets).
  • But when you start wanting 3D drivers, network transparency etc. you'll end up with something just as big as X anyway.
    I think there's a flaw in this conception. First, network transparency is not the great, unique feature it once was. VNC has a lot of advantages over X, and even if it has flaws (probably performance in certain cases), it is easier to fix than X. Even so, X could coexist with other systems if it was implemented ontop of something like the framebuffer. So you could have your cake and eat it too.

    While 3D drivers would have to be in the kernel, I don't think that's so bad. That doesn't mean OpenGL has to be in the kernel, just the necessary interface to the hardware. Interfacing hardware is exactly what the kernel is supposed to do. Linus just wimped out because graphic hardware is more volatile than most other hardware, and there was a crappy (X) solution already.

    But the reality is that X doesn't have the quality and security that the kernel has. Linux is not stable for me, because it's not uncommon that X blows up for some reason, leaving the kernel happily chugging along while the monitor and keyboard are completely frozen. If you don't run X -- like on a server -- it's easy to have great uptimes. Otherwise...

    Proper abstraction is what is necessary. All of X doesn't need to be in the kernel. Only the part that interfaces the hardware. The rest can be done (safely!) in userspace, as opposed to doing everything (very unsafely!) in userspace as X does.

    The framebuffer doesn't seem to be a good solution. I really think that KGI and GGI [ggi-project.org] provide a solid technical solution. But Linus has been very negative about those projects, unfortunately, and they seem to be moving slowly :-(

  • GGI, SDL, Qt (Score:4)

    by jfunk ( 33224 ) <jfunk@roadrunner.nf.net> on Friday January 05, 2001 @05:11AM (#528871) Homepage
    GGI, SDL, and Qt have been doing this for quite a while. Actually, when the framebuffer was added to the kernel (a long time ago) documents popped up about how to treat it like DOS int 13.

    SuSE and Caldera's installers use Qt under the framebuffer.

    Personally, I think SDL is a better fit than GTK for games. I downloaded the CivCTP 1.2 patch and the release notes mentioned that you can run it from the console now without X. It's experimental, though.

  • Another screenshot (Score:3)

    by jrb ( 11011 ) on Friday January 05, 2001 @05:15AM (#528875)
    Alex just posted another screenshot to gtk-devel-list. This one is of dia, and is a little more interesting then the ones above.

    http://www.lysator.liu.se/~alla/files/diafb.png [lysator.liu.se]
  • GTK+ isn't going to blow any life back into SVGAlib. The Linux framebuffer is not the same thing as SVGAlib. SVGAlib is a userspace library, that requires root access to do nasty things to your video card(like poking at its IO ports and memory directly). The Linux framebuffer on the other hand is an in kernel device, treated as a character device(I believe a mmap()able character device). So the kernel provides a nice clean interface to the video card, along with security policies of not letting the users do dumb stuff to it, or accessing memory it isn't supposed to. A lot of other UNIX OS's have a framebuffer, Solaris in particular comes to mind.

    The nice thing about this is of course, not needing suid on binaries just to get access to a graphics mode on the video card. There are X servers that utilized the Linux FB right now(XF86_FBDev in XFree86 3.3.x). Of course the drivers that are currently in kernel are not the fastest things on the face of the planet(yet).

    And BTW, the GGI project is basically dead, as their work was pretty much supersceded by the Linux FB.

    PS: Please make sure you understand what your talking about before you go on about people missing the point...
  • The framebuffer console is the replacement to SVGAlib. Instead of using SVGAlib as a means of doing graphics on the console outside of X, you can now just draw on the framebuffer console.

    GTK+ sits on top of the framebuffer console...if there were no fb, GTK+ would then have to sit on top of SVGAlib. GTK does not use your video card directly as you said above. The framebuffer does.
  • You wrote: Every font is anti-aliased, as are many of the lines, etc.

    How can you guys tell that this stuff is anti-aliased?? I personally, from the screenshot, can't tell. Remember, screenshots can be doctored because they are just another image file. On the other hand, it wouldn't surprise me one bit if I saw anti-aliasing in both this and X in all of the new 2.4 distros bound to be coming RSN since 2.4 is out!

  • the gimp, GTK apps on OS X? (Score:3)

    by option8 ( 16509 ) on Friday January 05, 2001 @05:56AM (#528882) Homepage
    GTK rendering without relying on X.. is that a step towards something like porting GTK to aqua, as is necessary to run the Gimp and other GTK apps natively in OS X?

    there's a short but informed discussion of such efforts at macgimp.com [macgimp.com] and i wonder if anyone here might be able to shed some light on whether this is helpful in that effort...

  • Will GTK become Yet Another X? (Score:3)

    by mdb31 ( 132237 ) on Friday January 05, 2001 @03:12AM (#528885)
    While I see why this development is cool and might solve performance problems for some individual applications right now, I''m not too sure about the long-term gains for all users here. Consider the following:

    1. As long as there are still 'legacy' X apps, you'll need to run X anyway;

    2. If GTK+ gets 'enhanced' to do some handy things X does right now (like, oh, IPC/RPC-based stuff), won't it just become another X, minus the compatibility with zillions of existing apps?

    Don't get me wrong, I'd love to see the architectural disaster that is X go, but I'm not too sure that GTK+ is the right way to achieve this...

  • If the screenshots don't seem <b><i>special</i></b>, you haven't looked closley enough!<p>
    Every font is anti-aliased, as are many of the lines, etc.<p>
    I also see that the test is not only multi-lingual, but there is advanced <b>BiDi</b> and unicode support with dynamic keyboard re-binding. This evidenced by the Hebrew and Arabic in menus, forms and text fields.<p>
    I think that this means that Pixbuf and Pango are along farther than I thought, and that a simple lib swap gets about any Gtk+ app/library running on the fb.<p>
  • I never said games used /standard/ widget sets, just that they use widget sets.
    >>>>>>>>>>>
    Sorry, "widget set" is a *NIX term, and when someone says it, the first thing I think of is GTK+, Qt, or somesuch thing. I think for games the appropriate term is "UI chrome" ;)

    That they don't frequently use standard ones is unfortunate, as it's Yet Another Task that game
    programmers have to do
    >>>>>>>>>>>>>>>
    Maybe, widget sets often CAN'T be used. For example, any windows game that uses DirectDraw or Direct3D cannot use the system widget set since everything except low level primatives don't work on DD surfaces. Also, using system widgets sets makes the game much less portable.

    And there /are/ still games like {Free,}Civ where standard widget sets are used... your blanket "games don't use widget sets" is wrong even if
    reinterpreted to refer only to standard widget sets
    >>>>>>>>>>>>
    Who cares about FreeCiv? If only .001% of a group does soemthing, it really isn't worth using the qualifier "most." EX. The statements "People don't castrate themselves on purpose" and "Most people don't castrate themselves on purpose" are functionally equivilant. Sure, it's a blanket statement, and some people DO castrate themselves on purpose, but the number is so small, it's not worth mentioning.

    BTW: Unreal also uses the system widgets, but only in some screens.
  • No X = No X Window management.

    Is this just meant for (a single) full screen app?
  • Most people don't remember that the whole point of X is to run applications in a network environment, even if they're used locally.
    Network transparency is just not a difficult enough thing to achieve to suffer the complexity of X. I mean, do you want to make your X server open to the entire Internet? No, of course not -- that's an incredible security hole. So what's the point? What network environment are you talking about? Your local LAN? That makes X worth it? Access from trusted computers is the same as a "network environment"?

    X does many things, and it does them all poorly. VNC is simpler and more robust for working over the network. 3D is patched on. Can you do 3D reasonably over the network? It's not very stable -- a rogue app can effectively kill the server (even if it's not supposed to). It doesn't do fonts well, so people are making systems that entirely ignore the X font system. The clipboard is lame...

    What does X do well?

  • But this is pretty cool for platform with no X, or for ports (say BeOS, or Mac OS X).

    For ports, "this", in the sense of GTK+-fb, isn't relevant; what's relevant is that ports can be done, to a large extent, by changing the GDK layer, rather than by changing stuff all over GTK+.

    I think the Win32 port [user.sgic.fi], which antedates the frame buffer port, was also done largely at the GDK layer.

    There are people working on a BeOS version of GTK+ - there's a GTK+ for BeOS page [gtk.org] on the GTK+ Web site [gtk.org], and somebody's been sending patches to the gtk-devel mailing list [gnome.org].

  • Good thing there's no such thing as "X Windows" then... Go read your man pages, call it either "X", "X Window System", or basically just about anything else. There's nothing called "X Windows". :-P

    /* Sesse */
  • Can you do 3D reasonably over the network?


    Yep. That's what GLX is for.

    From http://dri.sourceforge.net/glossary.html [sourceforge.net]:

    X11 is a networked windowing system. Your client and your server might be on different machines. GLX packages up OpenGL commands into network packets, spits them across the X11 network pipe, then unpacks them at the other end. This lets you run accelerated 3D remotely: the client could be a simulation on a mainframe, the display could be your desktop machine in your office. GLX does a number of other X11 related things that couldn't be packaged into OpenGL.
  • And then you boot the first kernel with...?

    - - - - -
  • Except that you need root privileges in order to use the framebuffer.
  • What exactly is your arguement? Sure game's use widget sets, but most use their own, custom ones, or derive one from something like SDL. My point is that most games don't use *standard* widget sets (the initial post was about GTK+, remember?) and most major commercial ones don't even use pre-made ones, but make their own in order to suit the mood of the game. Also, a widget set for a game isn't exactly the most challenging task, since they are simplistic and totally overshadowed by engine design.
  • Would you rather them be not pragmatic?

    MacDonald's and Microsoft are also pragmatic compromises--they manage to get the biggest market share quickly. That's roughly what Gtk/Gnome did. That compromise is only desirable if your goal is lots of market share quickly, not if your goal is to develop good technology.

    The great thing about C is that it is interfaceable with a number of languages.

    It's only "interfaceable" with a number of languages because it is the de-facto standard and everybody bothers generating the glue to interface with it. Otherwise, it's actually quite horrible for the purpose.

    glib/gtk is about the best-designed piece of software I've ever seen.

    It is capably written and one of the better designed pieces of C software. But try to take a look at other systems sometimes.

  • most of that memory is pixmaps that the server is holding on behalf of the other apps on your system.

    so, the earlier poster is correct when he talked about 'memory wrapped up in the X process'

Slashdot Top Deals

I have hardly ever known a mathematician who was capable of reasoning. -- Plato

Close