TrollTech Releases Qt 3.0

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

Comments

Professional user of QT 2.12

[anfloga]

And all I can say is, what a joy to work with this QT toolkit is.

Before I wrote software which uses QT, I wrote it using Motif. The designer that comes with QT is light-years ahead of any designer I've used for Motif. The "slot/socket" mechanism that it uses allows me to use a more abstract GUI design. And the geometry management is much nicer as well.

Just thought I'd throw those thoughts in. No, I don't work for Trolltech. Lykke til Trolltech!

Hope I said that right. It's been years.

Re:database functionality... why?

[jfunk]

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

Re:Binary compatibility

[elflord]

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)