Slashdot Mirror

← Back to Stories (view on slashdot.org)

KDE 3.0 Alpha1 Available for Developers

Posted by michael on from the as-unstable-as-windows dept.

Dre writes: "Just a few weeks after the release of the rock-solid KDE 2.2.1, the KDE Project today announced the release of KDE 3.0 Alpha1. Targeted at developers who want to get a head start on porting or writing applications to KDE 3, the release is pretty much a straight port of the KDE 2.2 branch to Qt 3. However, for developers this brings an impressive array of new features to KDE, including new database classes, new data-aware widgets, improved RAD development with a much-enhanced Qt Designer, a new powerful regular expression class (with full Unicode support), improved internationalization support (including the ability to mix different character sets in the same text), bi-directional language support (for languages such as Arabic and Hebrew), multi-monitor (Xinerama and multi-screen) support, better integration of pure Qt applications into KDE, and hardware-accelerated alpha blending. With the Qt port out of the way, the KDE developers can now focus on the planned KDE improvements. Read the full announcement here, or go straight to the source (alternative link)."

3 of 294 comments (clear)

  1. Re:Great, just what we needed by fault0 · · Score: 5, Informative

    > KDE programs are
    > very slow to compile
    use ./configure --enable-final
    this reduces compile times by more than half, in my experience

    > and load.
    Use objprelink.

    > but the point is that KDE is a hell of a lot slower than GNOME.

    From what? Load times? Look at other big applications written in C++ and compiled in g++, like Mozilla and OpenOffice. They tend to load slow too. If you actually look at speed of applications, KDE wins hands down. Konqueror versus Nautilus. Konqueror wins. KOffice versus StarOffice/OO, KOffice wins. Other components tend to be around the same speed.

    > So, from my perspective, which is not that of a compiler designer, GNOME is a lot freaking faster than KDE.

    Yeah, "ordinary users" don't even compile KDE or GNOME.

  2. Re:Are there no new speed enhancements... by debrain · · Score: 5, Informative
    Yes, a pre-linker is what is being done with GCC. You might notice that kdeinit may run everything in KDE, from konqueror through konsole; that's because kdeinit is already linked. This is annoying when looking at the actual processes running. They're all kdeinit. Especially annoying for killing those zombieish konqueror sessions.


    The pre-linking relies on the fact that once libraries are loaded, they never move in memory. That could be a false assumption, but the gcc team is going to great ends to make sure it isn't. The issue as demonstrated is that 'helloworld' will be much larger, and much slower to load when it links against the QT libraries (or any large set of libraries). Thus, similar performance is lost when starting KDE applications linked against the QT libraries simply because they are all loading the QT library linkages.

  3. Re:it seems KDE is falling behind by Jagasian · · Score: 5, Informative

    Most of my expertise falls into software development in Java, but recently I have been pushing myself to do more C++ development on Linux. I don't want to rely on proprietary languages. Anyway, the modern C++ is far far different from the C++ of many years ago. Things have changed, and C++ is growing up. Sure its a very complex language, if you try to learn the legacy aspects of it, but if you stick to the core OO constructs in C++, then you have a nice efficient programming language.

    I am coming to realize that Java has very little over C++. Garbage Collection is more of a buzz word than an actual worthwhile feature, and it should be noted that high-level memory leaks are still possible in Java. Sure they are memory leaks of a different kind, but unreleased yet unused memory is a big problem in many large Java software systems.

    In addition, for even an intermediate software developer, how difficult is it to code your own destructors? I mean, really, at worst you have a few loops in a destructor. Anyway, most JVM garbage collectors are unpredictable and hog performance at the worst of times.

    The most important thing that Java has over C++ is a comprehensive set of user-friendly yet powerful APIs. But in return, C++ as templates and STL, allowing for elegant generic software systems.

    When it comes down to it, C/C++ are here to stay, until some real yet practical innovation in Functional Programming languages, mobile/concurrent languages, or Declarative Programming languages is made. I am all for newer better higher-level programming languages such as Haskell, Pict, Lolli, and Mozart-Oz, but Python, Ruby, C#, and other newer procedural/OO languages are not the revolution, they are not the future, and at best, they are nothing more than slight iterative improvements on an overused overdone, and over talked about paradigm.

    Give me C, give me C++, and if you can, why don't you give me something new for once? I am tired of the same old Ford Tempo with a new paint job and a new name.