What to Expect From Qt 4

An anonymous reader writes "A presentation given by Matthias Ettrich (director of Qt development, author of LyX, and founder of the KDE project), was given to the annual KDE Developer's Conference in Nove Hardy, Czech Republic. In this presentation, Matthias details what's going to be new in Qt 4.0, which will be used as a base for the next version of KDE after 3.2. Apparently, Qt 4.0 will not only include faster startup times and lighter memory usage, but will have sweeping architectural changes, including a splitting of Qt's GUI classes and non-GUI classes."

Comments

Re:It Sounds Nice

[siliconwafer]

The lighter memory usage and faster startup times sound very nice. Maybe not essential, but nice.

Re:It Sounds Nice

[stratjakt]

Qt 4 mostly tries to preserve source-compatibility with a little search and replace and a COMPAT compilation switch. More porting will be required for styles and code that uses the meta object system directly.

Out with the old, in with the new.

Developers can adapt or fail. It doesnt seem wise to quit working towards better systems because some guy doesnt feel like replacing his widgets.

gcc dynamic linking?

[4of12]

A couple of years ago someone on the KDE team posted a nice analysis of the performance bottlenecks associated with dynamic linking, C++, and gcc, particularly as regards Qt use.

So I have to wonder, with Qt 4, KDE 3, gcc 3.3, how many of the performance problems remain?

Re:gcc dynamic linking?

[IamTheRealMike]

That's what all the talk about reducing number of symbols and relocs is about - KDE got hit really really hard by the way it requiries lots of fixup at startup time in the linker. In some cases it was THE biggest drain on startup time. By reducing the number of symbols in the code, you reduce the work needed to dynamically link it all, so improving the speed.

Though, I can't help thinking that prelink is a better solution to that problem. But whatever, they are surely aware of that technology by now.

use of the standard library

[Eponymous Coward]

I'd like to see more use of the standard library. The traditional complaints of poorly conforming compilers is mostly just history. Except for support of the export keyword, most C++ compilers and standard library implementations are now quite good. Most platforms even have several excellent compiler / library combinations to choose from.

Even though it would be hell for already existing apps, I would love to see use of standard library components rather than the re-invented QT versions. And even in those cases were the QT versions have extra features, I still think the advantages of using a library that is already familliar with most C++ programmers outweighs the disadvantages. Of course, that's just IMHO.

ec

Re:It Sounds Nice

[Otter]

Developers can adapt or fail.

Remember, though, that we're talking about volunteer developers. If they fail, there's no one rushing in to take their customers. I remember when the KDE 3 plans were being made, there was a recognition that KDE's weakness is in the number and quality of apps and so there was a goal of keeping the APIs stable for as long as possible.

Now, greatly improved startup time would obviously be a huge reason to switch as soon as possible. Since pure Qt apps already start much faster than KDE apps, though, I wonder how much speed KDE would really gain.

Very nice. But they forgot one minor thing:

[master_p]

I don't have any major complain from Qt, as I have been using it a lot in our company and found out that it is the best.

I only have this problem: the TreeView widget is single-linked. This a major problem for us, since our apps contains lots of trees. We have to do a lot of tricks, like keeping a pointer to the last item all the time.

I've posted this on the Qt newsgroup but I was ignored. Although many people have complained about it, Qt engineers ignored us. I think they should fix it in version 4.

Other than that, Qt is indeed the finest toolkit out there. It simplifies development a lot, and it fills the great void that exists in C++ libraries. It's really like the Java libraries or the .NET libraries, providing almost everything needed under the sun.

The biggest advantage of it is that it works as expected; in other words, you just create one widget inside the other, and voila, there is the app's gui. You can even do it programmatically, without the KDesigner.

Finally, it does C++ justice. It's the only library that shows how powerful C++ can be. After having used Qt and Java, I may safely say its up on par with Java...even better I would say, since it uses all of C++ capabilities, including the most important one: templates.