Slashdot Mirror

← Back to Stories (view on slashdot.org)

Gnome Development Roadmap

Posted by Hemos on from the mapping-out-the-future dept.

dfallon writes, "A GNOME development roadmap is available over on developer.gnome.org. Highlights include: a 1.2 release targeted for April, followed by another 1.X release in late summer (1.4?), which will include Nautilus, the desktop shell being worked on by Eazel, which will lead into a 2.0 release sometime in the fall. " This is, of course, subject to the mad revisions of Nat and Miguel - but it's cool to see what the future /might/ hold.

5 of 309 comments (clear)

  1. Let's have the KDE v. Gnome debate one more time. by pete-classic · · Score: 5

    I have a general question, and then some personal observations.

    First, isn't the religious reason for Gnome the fact that QT is not GPL, and KDE needs QT? Maybe I fundamentally misunderstand the situation, but couldn't the effort that created Gnome have created a GPL work-alike to QT? In fact, as I recall, the KDE developers could not even VIEW the QT source when KDE was originally written, so mimicking the documented interface and functionality of QT should have been trivial (from a design standpoint. I am not trying to minimize the amount of work involved.)

    This is not a troll. I intend this as a serious question. I am sure that there is a perfectly valid answer, that is why I am asking.

    With the above aside:

    In my personal experience KDE is slow on a slow system, and fast on a fast system. On the other hand, Gnome is S-L-O-W on a slow system, and slow on a fast system. As a matter of taste, I prefer KDE's less "frilly" appearance, and find it nice to use. Gnome is not bad, but I don't see what the performance penalty is buying me.

    The general response to this question is "Gnome is not slow for me." If this is true for you, perhaps you have some configuration hints you can share. I don't have any benchmarks to back up my impression that Gnome is (considerably) slower than KDE on the same hardware, but a lot of people agree that it is a dog, and I don't think that it is just a conspiracy to get people on a slippery slope of using non-free (lebre) software (in this case QT.)

    The short version: Why should I run Gnome instead of KDE, assuming that I don't care about QT licensing quibbles? What do I gain for the (possibly only perceived) poor performance of Gnome.

    (To disclaim again, I am posting these questions in good faith.)

    -Peter

  2. Rasterman defumigation? by Anonymous Coward · · Score: 5
    Has anyone else noticed that Gnome(Red Hat) has defumigated themselves of everything that Rasterman had touched?

    • Imlib replaced by gdk-pixbuf
    • esound no longer a requirement
    • enlightenment replaced with Sawmill
    • anything else I missed?

    Coincidence?
    Raster might create beautiful innovative eye candy but I've looked at his code and it exactly matches what others have said, "what a mess". Well Raster is a rock star of the Linux world, but are Open Source rockstars a good thing? Hmmm, what is VA going to do when Enlightenment is not included on the next release of RedHat? That will be a sticky situation.
    1. Re:Rasterman defumigation? by AT · · Score: 5

      Enlightenment is still the default window manager in the Redhat 6.2 beta. I'm sure that if it is retired as the default, it will still be part of the distribution for a long time to come.

      Despite the fact it has grotty code, it pretty much revived the whole window manager scene and showed people X could look nice. Widget set themes either directly or indirectly owe their existance to E and Raster. I remember 1995 when fvwm and Xaw were king, and I thank Raster for getting us past that.

      That said, imlib was fundamentally flawed something had to be done. It probably could have been fixed, but the GNOME developers chose to reimplement the functionality. Reimplementation is not always bad -- lessons learned the first time can be fixed. From what I've heard, esound has (or had) some pretty serious problems; perhaps they are being worked on, or replaced.

      Remember VA Linux makes its money selling hardware for Linux. Anything that makes Linux better is good for VA; whether it is Raster's code or someone elses doesn't matter. They probably pay Raster to do what he has done: trailblaze some interesting ideas that make Linux more appealing, visually or otherwise.

  3. flaming overestimated by mattdm · · Score: 5
    There was a post like this last time this discussion came up, and I noticed the same thing: lots of comments on "oh no, look at the flamewar that always explodes when this comes up", and very few actual flames. (And, thanks to the moderation system, any that do happen are relegated to the bottom of the heap.)

    So, I'd like to propose that next time there's a Gnome or KDE article, people just skip commenting on the theoretical but largely imaginary flamewar.

    --

  4. Speeding up GNOME: Tips by ajs · · Score: 5
    GNOME has several pieces, and each can be approached seperately. First, the window manager. GNOME is window manager independant, so if you don't have a kick-ass system with at least 128 MB of RAM, I suggest ditching enlightenment. Go with sawmill or icewm or one of the other WMs.

    Next comes widget themes for Gtk+. Keep in mind that themes that have pixmaps for every widget take up a LOT of memory. The flat-colored themes are the least expensive, but least visually apealing. Try looking at the various theme entries on themes.org and note the sizes. Pick a list of your favorite themes and use the one with the smallest size (the size of the theme is not a perfect guage, but it's a good start).

    If GNOME still seems slow try these tips:
    • Don't use transparent windows, and if you must, don't use shaded transparency
    • Exit netscape if you're not using it. It's a pig.
    • Don't run GNOME and KDE apps at the same time. They both have huge libraries.
    • Grab the source for glib, gtk+ and gnome-libs and re-compile with "-O2 -finline-functions -mxyz" where xyz is your platform (e.g. "pentiumpro"). The GNOME coding standards require lots of little functions, so the "-finline-functions" parameter will really help.
    Hope this helps!