Slashdot Mirror

← Back to Stories (view on slashdot.org)

TrollTech Releases Qt 3.0

Posted by Hemos on from the comin'-at-you dept.

Dr. Sp0ng writes: "TrollTech released Qt 3.0 today. Among the new features are platform- and database-independent data-access features, data-aware GUI widgets, a much-updated Qt Designer, and much better internationalization and font handling features. It breaks binary compatibility but keeps almost complete source compatibility with Qt 2.x. The KDE team has already begun work on KDE 3.0, which will use the new toolkit."

2 of 285 comments (clear)

  1. Re:database functionality... why? by jfunk · · Score: 5, Interesting
    A bunch of points in no particular order:

    • Qt was never intended to be just a GUI. It was intended from the beginning to be a RAD environment. That means simplifying many programming tasks including, but not limited to: GUI stuff (QWidget on down), string use (QString, etc.), internationalisation (i18n, QtLinguist, etc.), 3D graphics (QGL), and the elimination of evil callbacks (signal/slots are my very favourite feature). You can also create non-GUI apps under Qt, if you want (KDE's 'dcop' command is an example. try an 'ldd' on it)
    • Database functionality is actually quite important for a toolkit such as Qt. Have you tried Kylix? It's biggest selling point is it's DB functionality. It's really simple to quickly create DB apps, even if you can only use MySQL or Interbase. We have it where I work but we use PostgreSQL. I will definitely be trying Qt's new DB functionality
    • Do you *really* want to make a frontend in Qt and a backend in Java? If you're going to use Java, you might as well use Swing or Awt for the GUI bits. Besides, I've seen some terrible experiences with getting different Java programs running under various JREs on Windows. If you can simply compile a binary and an installer, then the user only has to install one thing and can avoid JPain


    OK, not so many points as I thought...
  2. Re:Binary compatibility by elflord · · Score: 5, Interesting
    While having open-source code makes source compatibility easier to handle than binary compatibility, I've been wondering if there has been any work towards improving binary compatibility between versions of major libraries.


    The short answer is yes, there has been. The biggest problem has been with the C++ libraries, and g++ is finally standardising on a stable ABI.
    As for Trolltech, they've always worked hard to maintain binary compatiblity (eg minor releases are binary compatible), indeed there were more
    problems with binary compatiblity caused by libstdc++ issues than with Qt itself. I'm not
    sure that KDE has been as stable, though this
    should improve. (The move to DCOP resulted in growing pains)


    To get some appreciation of how fragile binary compatibliity is, read this. Binary compatibility is fundamentally
    difficult to preserve in C++, and I don't think there's any clean way around it. Fundamental
    changes in interface or exposed structure
    (that means anything besides opaque pointers) will break binary compatibility.


    Personally, I think the fundamentals need to be
    nailed down. C++ and C libraries need to preserve
    binary compatiblity. On the other hand, I don't
    think there's a problem with other libraries, so long as they maintain binary compatiblity across minor releases. (users could install multiple versions of the same library)