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

Faster?

[Kenterlogic]

I have alwways preffered Gnome to KDE because of speed issues (and the new Gnome is a lot prettier). But if this new base is much faster, then I may be forced to start using KDE again. Then again, my G5 should be arriving soon-- so forget Linux.

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.

This might mean something to me

[Anonymous Coward]

if their licensing policy didn't suck. I write low cost software (not "free", not "encombering", reasonably priced) and the QT licensing does not allow me to use it. They pretty much say "Fsck you" in their licensing FAQ to such developers.

Too bad, I liked their stuff, but luckily there is wxWindows...

Re:This might mean something to me

[phurley]

I use and enjoy wxWindows, but I do not think your criticism of QT and their licensing is very fair. They have a completely free license (GPL) which you can use - to create completely free applications. They have commercial licensing (admittited too expensive for "shareware" type applications).

There is a completely reasonable middle ground where you can release your application as GPL code - which you can legally sell for any price you want - yes you need to provide the source code to your customers (not a bad thing) and yes they can then give it away to their friends, family and even people they pass on the street - but if your application has true value - they will probably be more than willing to pay for it (especially if it is as low cost as you claim). Many users are not sophisticated enough to compile their own binaries and the making the "official" binaries what you sell - is legal.

Now if you are just upset because they will not give you (or sell at the price you pick) their library for you to use in closed source for profit applications, then it is far better that you found a different library.

Re:This might mean something to me

[Cthefuture]

As others have mentioned, the problem isn't that we don't want to pay for a license.

I have no problem paying for QT.

I have a MSDN subscription in fact. That MSDN (Professional) was around $1000. Not too bad considering you get every single MS OS and the whole development environment (C/C++, C#, Java, VB, etc.) and all sorts of other bits. For the most part Microsoft is very good to their developers (hey, they make them money).

Compare that with QT which is around $3000+ for all three platforms (or what, $1500 for one platform?!). And it's only a GUI toolkit (sure, with some extra "fluff"). Way, way too expensive for what it does. If QT was $1000 for all three platforms, then I'd own several copies And many, many other people feel the same way. Their license prices are holding them back. They would have so, so many more developers working in QT if their prices were reasonable. That would only help them in the end as I have a strong feeling the world would become more QT-centric (I mean, it is a pretty good GUI toolkit; although the current stuff is rather slow).

Re: RTFA!

[Rimbo]

Jesus, I was wondering when someone was going to say this. Qt developers obviously aren't reading slashdot. other than you and me, that is :D

I think the large number of complaints is that although source-compatibility is -basically- maintained, you still have to recompile your apps. One of the nice things Microsoft has done is that you don't have to recompile your Win32-based app to work in .NET -- well, not completely, anyhow. This does have the side effect of dirtying up the API a bit. So it's a trade-off. Backwards compatibility does make GUIs easier for people to adopt -- who wants to constantly have to download new apps to work with the latest version???

New versions alway better in the long run

[jj00]

Now this is what I like about Linux; every time I think some annoying little thing about the interface/OS is really starting to annoy me, a new version comes out and something get tweaked to the way I like it.

It's really the reason I have grown to like Linux so much: I can actually see the progress of its development moving forward. It seems in the past few years that Windows has just been moving backwards.

What I would like to see..

[ErisCalmsme]

Is more apps that require QT but not all of kde to run. That's why I use gtk apps... because most of them dont require gnome. There are gnome apps of course, and there are progs like Gaim that will give you a little somethin' extra if you have gnome installed, but you don't need it... Are there any qt apps that dont require kde to be installed?

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

[Jeagoss]

Besides reading my profile, what is to say I am even talking about QT for a personal use, or even QT for linux. I work for a company that uses the Professional Version of QT for development of "in house" applications which run mainly on FreeBSD. Source compatibility isn't always the best thing. A recompile of our applications isn't the quickest thing either. And after the recompile, we still have policies that say we have to test the new compiled app for 2 weeks before we push it to the network, just to make sure everything is stable. Big change costs money. Our company is far from scared of change. We just need to consider the investment of time and manpower to cope with it.

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.

Re:Very nice. But they forgot one minor thing:

[Anonymous Coward]

Then you and your friends need to stop drooling over stupid American muscle cars and get a clue -- java.util.Vector has been around forever, and java.util.ArrayList has been around since JDK 1.2.

Re:QT4

[SlayerDave]

It is matter of personal preference, to some degree. Personally, I prefer the EventListener mechanism in Java Swing to the signal/slot mechanism in QT. Of course, C++ does not support anonymous classes, but it does support inner classes with the same scoping (I think) as Java inner classes, so it would be relatively easy to write small Listener classes, registered with the appropriate widget, to handle callbacks and events. Again, personal preference.

I should admit, though, that my main annoyance with the Qt signal/slot mechanism is that it confuses Emacs, screwing up indentation and syntax highlighting. Annoying, but not enough to make me stop using QT.

How about more standard C++

[Ed Avis]

Is it too much to ask that the next Qt will use the standard C++ string class instead of its own reinvention and kitchen-sink-itis that it suffers from at the moment?

Re:How about more standard C++

[Ed Avis]

Well, to be honest, the QString class is substantially more powerful than the C++ string class. Most especially in casting to and from other data types.

boost::lexical_cast

Well, okay, I'm proposing a third party library to provide what Qt's string class has built-in. But in a way this illustrates an advantage of using the standard string (or other standard classes) rather than rolling your own. You are able to take advantage of lots of third-party code, including the excellent work at boost.org.

Moreover, it supports the full range of internationalised characters,

You can make a basic_string of whatever character type you wish, including wchar_t. I guess it's unfortunate that the standard 'string' is an alias for basic_string<char, ...> instead of using 16-bit or 32-bit characters, but it's not a disadvantage of the string class itself.

it automatically casts as neede and passes by value as needed as well.

The standard C++ string has value semantics, so you can pass it by value (and usually do so efficiently). In this respect it's just like an int - you can pass and return strings by value, and two strings are equal iff they have the same characters.

I'm sure the Qt string class is great, the question is, is it so much more wonderful that it justifies being different from the rest of the world?

AC Comment from other Canopy Employee

[bstadil]

Since my comment has been modded a Troll I think you should read this posting from another Canopy Company employee.

Quote:

As an employee of a company in the same office buildings as SCO and partly funded by Canopy Group, I strongly encourage a boycott of all companies funded by the Canopy Group.

There was a lot of buzz about mergers a few weeks ago. It seemed that everyone was going to join into one large company called, you know it: SCO! .......

Re:HTML rendering

[julesh]

Have you looked at this to solve your windows portability needs?

http://kde-cygwin.sourceforge.net/

It uses cygwin, which might mean some user confusion with filenames; if that's an issue for you you might want to forget about it. Also it'll mean you're stuck with GPL. Otherwise, I understand the results are quite impressive... if you don't want to use X, you can probably substitute the windows version of Qt, and everything should work OK. It'll be a lot of work to get it going, but after that it should be stable and usable...

Moderators Suck ...

[Anonymous Coward]

Troll? Come on guys, we're not bashing Apple.
You don't have to throw a hissy fit cuz someone's bashing your fave tool.

from http://www.pclinuxonline.com/modules.php?mop=modlo ad&name=Forums&file=viewtopic&topic=870&forum= 37
As an employee of a company in the same office buildings as SCO and partly funded by Canopy Group, I strongly encourage a boycott of all companies funded by the Canopy Group.

Taking money from Ralph Yarrow (Canopy) made all of us sick to our stomachs but we held our noses and moved into their offices in the hope their stake would stay small. And we were out of business if we didn't.

There was a lot of buzz about mergers a few weeks ago. It seemed that everyone was going to join into one large company called, you know it: SCO! That buzz ended yesterday. Now the talk, all over the group, is how to distance ourselves from SCO and Canopy. The mention of our company on Slashdot resulted in very negative feedback and two potential customers walking away. Other's got it even worse. I hear Trolltech spent most of the day on the phone smoothing things over with their customers. Upper management meetings were held all afternoon among the group's companies (I'm not privvy to those, but can guess the subject matter). Companies that were considering a merger with SCO (some as close as 5 days away) are now backpedalling as fast as they can.

Canopy Group is the key to pressuring SCO. Thats where they get their money and their actions could harm the whole group and Canopy's plans. Pressure on the Canopy Group's members will result in pressure on SCO.

Save me from SCO! Boycott Canopy Group. If they want to point a gun at their own head, I'd rather they do it away from me. Write letters to the all the Canopy Group companies. We are all very small and even a few letters would have a major effect. The three we received yesterday sent management into a tizzy. Oh, yeah. And start at the bottom of the alphabetical list of companies, please.

Thanks for listening...

-------- more --------------

Ignoring your personal attacks, the point remains that the pressure point here is Canopy and their group members. SCO could care less about a boycott, Canopy will continue to funnel money to them. The key is Canopy and Canopy is vulnerable through their holdings.
Ralph Yarrow cares about only one thing: the bottom line.

Only three emails to my company convinced mangement that there was a problem. They spent most of the afternoon in closed door meetings deciding on how best to distance themselves from this mess (at least that was the discussion when I was called into offer my opinions). They dreamed of the day we would be slashdotted, but are very dismayed that when it finally happened, it was entirely negative and harmful. From my colleagues in other companies, I gather the scene was common all over the office park yesterday. A couple hundred more emails will have a dramatic impact. The pressure will proceed directly from companies of the Canopy Group up to Ralph. When he sees the bottom line being attacked he will rein in SCO.

Some have said that it is unfair to punish the other companies. But the other companies are already being punished for SCO's actions. We have already lost potential customers who informed us they did not want to be associated with Canopy/SCO in any way. My product's release date has been placed on hold indefinitely while this uproar is going on. I fear this nonsense will ruin us. It would be foolish to start the rollout under this dark cloud.

The party line from SCO is that the opposition is from just a few disgruntled 'pot-smoking hippie-types' that can be ignored and they will go away. (From an overheard conversation in the restrooms. No doubt, Monday morning SCO employees will receive news of a new policy about talking in the restroom. But it wasn't the employees forgetting to check the stalls before tossing around disparaging remarks).

Give them a reason to

Re:It Sounds Nice

[sketerpot]

From the article:

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.

Not much Qt code uses the moc system directly, since this is deep black magic and typically a bad idea. They're preserving compatibility, and it seems like a pretty small price to pay.

Re:QT4

[Admiral Burrito]

That's true, the Java API has a very large number of classes. But what I like about their docs is the use of frames, which is normally quite annoying, but is well-done in the case of JavaDoc.

I find javadoc frames annoying. Easily fixed of course, just use the non-frames version.

My javadoc navigation solution is to create a folder on my mozilla personal toolbar with bookmarks for the packages and classes I refer to most often, and one for the package list (so I can reach the other packages). It's like a separate bookmarks button just for java API stuff. Works pretty well for me.

Re:I use linux but IANALH (I am not a linux hacker

[be-fan]

Qt4 will definately help in some ways. In particular, the fact that all widgets will now be double-buffered (instead of just most of the widgets) means that a lot of tearing will go away. Startup time should be reduced a little bit as well. Hopefully, a lot of work will go into fixing synchronization issues, which is the real problem holding back X-based GUIs.

KDE itself is getting much better. I'm using a CVS version of KDE, and can say that things are *much* faster. Konqueror starts instantly, and most apps start in less than 2 seconds. Konqueror has zero rubber-banding when resizing medium-complexity websites, and hardly noticible rubber-banding when doing reflow-heavy sites like Slashdot. The KOffice apps are all very fast, none exhibit any rubber-banding at all and all start up in a couple of seconds. All the standard widgets are really fast --- Juk for example, resizes with zero redraw even with a 2000-item listview. The only apps that really need work are those that use custom views or widgets (like Konqueror).

My setup is KDE CVS from Aug. 8, 2003. I'm Gentoo 1.4 on a 2GHz P4.