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:Still not open-source though

[jonathan_ingram]

I'm sorry but I have a huge problem with running KDE when there's a dependency on proprietary software.

Although you are stupid and misinformed (no closed source software anywhere in KDE), with your attitute, you should prefer KDE to Gnome. QT is GPLed, which means that if you want to write commercial applications using it, you have to pay Trolltech for an alternative license. In contrast, the whole of Gnome is no better than LGPLed, which means there is nothing stopping commercial software.

KDE is therefore the better choice for those like Richard Stallman that believe that all software should be free.

Re:GNOME?

[Anonymous Coward]

You aren't talking about reasonable people here, you are talking about GNU (who stands behind gnome). They are to the computer-scene what the Talibans are to Afghanistan, totally fanatic people who just will not act reasonable in nay way.

They just hate that people can freely sell their own work (trolltechs sells QT licenses) out of their own will.

Re:Qt? Who needs it...

[jonathan_ingram]

Yes, it's strange that wxWindows has been ignored by the wider Unix community... from what little I've seen of it (mainly in relation to wxPython, the Python bindings for it) I've been very impressed -- particularly compared with Tcl/TK (or tkinter, the 'standard' Python GUI system).

There is some nice software like Audacity and Roxfiler using it, but nothing like the amount that *should* be.

Re:Qt? Who needs it...

[Dominic_Mazzoni]

Amen!

The really cool thing about wxWindows is that at any time somebody could write wxQt, and immediately all wxWindows programs could integrate with KDE as well as they currently integrate with GNOME.

I haven't regretted for a second choosing wxWindows, even if nobody ever writes wxQt, but I sure do like my KDE desktop.

Finally for the Mac!

[SeanAhern]

One of the most exciting pieces of news about Qt 3 (for me at least) is that it supports Mac OS X. And I'm not talking in X11 mode running XFree86. They have a true Quartz/Aqua implementation that runs natively, including OpenGL support.

So finally, all of those apps that use Qt to port to Windows now immediately port to Mac OS X with a recompile. Good show, Trolltech!

Read more from their press release.

Kapps for Mac OS X?

[Tachys]

Does this mean that in the future we will see Kapps like Kword and Kmail on Mac OS X?

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)

Re:database functionality... why?

[elflord]

Okay, here goes.... why oh why is QT in need of database support. It is a cross platform GUI (last time I checked?)

No, it was never just a GUI library. It also included a container class library, strings, streams, graphics file manipulation, and more recently, it has an OO socket implementation, and XML support (Sax and DOM) You're on to something with your Java comment though -- think of it as a C++ version of the Java standard library, if you like.

Re:Binary compatibility

[Ian Bicking]

Doesn't the standard ABI only address binary compatibility across libraries compiled by different compilers? I.e., now you may lose binary compatibility between otherwise compatible libraries if they are each compiled with a different compiler.

But won't you still lose binary compatibility when you change the source sufficiently? For instance, don't most C++ compilers use offsets to refer to the various instance variables, and won't those offsets change as you add or remove variables?

I suppose for virtual methods calls you could preserve binary compatibility. Does Qt use virtual methods for everything?

And if everything was virtualized, wouldn't C++ be about as efficient as Objective C (or maybe even GCJ'd Java)? Or is there some fancy translation that C++ will do when linking, for a one-time-only cost (for each application startup, but not every call)?

I know little about the internals of C++ compiled code and linking, so I really don't know.

Question about Steven's comments in Dr Dobbs...

[MeerCat]

Not wanting to troll, but in October's Dr Dobbs (pages 105-107), Al Stevens points out what he doesn't like about Qt - primarily the way that the framework breaks the "new/delete" idiom. In particular, widgets must be allocated on the heap and then given to the framework to manage and delete. (When I last looked at Qt I though the same sort of thing but thought maybe I was being a little too snobby and showing my age).

As I said, I don't want to troll, but for those who're using Qt/KDE is this a big concern ? Do you write a handler wrapper class around widgets that hides this mis-match, or do you just live with it ? Does it only happen in one or two spots ? Is short - how do you change your practices to match the toolkit ?

He also dislikes the metaobject compiler and a few other items, but I'm less concerned about those...

T

Re:Question about Steven's comments in Dr Dobbs...

[anno1602]

Having looked at MSFC (yuck!), GTK and Qt, I find that Qt is the toolkit that makes UI programming the easiest. And frankly, I don't quit get what you mean with your new/delete idiom breakage. It all works the very same way as in standard C++, except for two things:
1. Include the QOBJECT macro in every class you want to use Qt in
2. You don't have to bother deleting Qt Objects. It's done by Qt.

I think it's great. How is this bad?

Anno.

Re:Question about Steven's comments in Dr Dobbs...

[MeerCat]

Having looked at MSFC (yuck!), GTK and Qt, I find that Qt is the toolkit that makes UI programming the easiest

I agree MFC is nasty (I almost had to use Glockenspiel CommonView 10+ years ago, and MS just stole the entire team to write MFC version 1 - I'd already written my own C++ wrapper by then).

except for two things [...] You don't have to bother deleting Qt Objects. It's done by Qt [...] How is this bad?

When you have a large body of code evolving over a period of time, you often want to check such things as resource leakage. This normally means checking that all allocations match up with deallocations (with a GC-ed resource you do this by checking all your GC code works and by checking people use the GC properly). You check this by matching up alloc and de-allocs of whatever resource it is.

If you have a single block of code that runs

alloc resource
use resource
free resource

then you can easily see that this resource is handled properly (ignore true exceptions for now).

On the other hand

alloc resource
if resource allocated
use resource
free resource
end-if

is also correct, but

alloc resource
use resource
if some-condition
free resource
blah-blah-blah
if some-other-condition
free resource

is usually wrong - it breaks the idiom - reviewing this code should set off alarm bells as allocs and frees don't directly match. If the code is genuinely correct (say the 2 conditions are mutually exclusive) then you have to mark it in some way to say "this misuse of the idiom is correct" - often you "mark it" by refactoring the code to use the idiom

alloc resource
use resource
do-the-commonstuff-here
free resource

In C++ the standard idiom is "object construction is resource allocation", and this makes exception handling and some of the refactoring easier - you allocate the resource in the constructor and free it in the destructor. Again, for the reader/reviewer it is easy to see where allocs and frees match up and prove the use is correct

class blah
{
blah() { alloc resource }
~ blah { free resource }
reset { free resource; alloc resource }
}

Again, this is not language specific, but idioms that make it easy to see when your code is correct. That's why adding a function to the above class

set(r) { free resource; resource = r; }

is nasty - you have an unbalanced freeing of a resource so to prove its correct you have to show that everyone who calls set knows how to use it properly. This seems to be the Qt idiom.

How is this bad ? Add 5 years of development with a rotating team of 10 developers (say turnover of 2 a year) and management, and a medium sized code base of 250,000 lines of code across 25 libraries and a dozen executables.... it's 10pm on the night before a release - do you know where all your allocs and frees are ?? On a small project or a small codebase you can hold it in your head "don't worry about these special cases" but in the larger case it makes for problems, and I put enough bugs in my own code without idioms that encourage me to introduce more. I can think of ways to code around it (a wrapper that allocates the class and gives it to the Qt framework, a bit like auto_ptr) but why doesn't Qt do this for me ?

Long answer to a short question - sorry....

T