Trolltech Releases Qt 3.1

Isle writes "Trolltech has today released Qt 3.1. Qt is the C++ library behind KDE and this release means that the road is paved for the KDE 3.1 RC4 monday to become final. Here is a list of major new features. Among those are Qt Script for Applications, better integration with Mofit and an improved build system."

Comments

Qt slow, annoying

[0x0d0a]

I still think that Qt is easily the worst thing about KDE. It supports few languages (and only C++ well) unlike the huge array of languages with excellent gtk bindings, it's much slower than gtk, it's large (and brings a lot more baggage with it than I want for a simple widget set), it fails to use the STL, every packaged version I've used screws with and then fails to clean up my ld.so.conf...

I don't find the widgets that attractive. Qt lacks gtk's incredibly useful dynamic keybinding features (in any gtk-using program, drag your mouse down to a menu item, and while holding the button, hit the key combination you want to bind to the key).

The licensing thing isn't as bad as it used to be, but it's still frusterating. Some people have said that this needs to be the case for Qt to be funded -- well, gtk manages without putting annoying licensing into their product, and I'm not entirely sure that something as fundamental as a (intended to be universalized) widget set should be controlled by a single, private organization.

Just my thoughts, and I'm sure some people (Guillame Laurent, and the ever-vocal Mosfet) probably feel quite differently...

Re:Qt slow, annoying

[0x0d0a]

Well, there's Python, Perl, Java, C#, Ruby, and C++ according to the KDE docs. Not bad, but pretty lame that it can't even do a single functional language, much less Objective C.

Gtk has Ada, C++, Perl, Python, Common Lisp, Eiffel, Erlang, Guile, Haskell, Java, JavaScript, Objective-C, Objective-Caml, Objective-Label, Pascal, PHP, Ruby, TCL, TOM, and XBase bindings.

GTK+ has a native (not a preferred) language specifically chosen because it's least-common-denominator. The Qt people evidently didn't see compatibility with less-used languages as important, so they snubbed everyone else.

Qt uses the STL.

Really? When did they lose the QString and QVector class and other ugly warts?

And it's bigger because it does a heck of a lot more than widgets-only GTK+

Which is a *bad* thing, violating the UNIX design principle of many small parts, each the best for its job. I frequently use glib even in projects that I'm not using gtk+ in -- I find it makes C a joy to use. You can't do that with Qt -- it's all or nothing. I don't want a bloody "platform" on my computer. I got my fill of that with JVMs. Qt is bloated, and far more so than gtk.

GTK+ manages with the LGPL because it is a free beer library.

Okay, I miswrote. My point has not changed -- if you want to put it that way, Qt is not a free beer library. And that's a sorry state of affairs.

The impression I got is that Qt pretty much exists to pander to ex-Windows types, who are used to coding in C++.

Re:Qt slow, annoying

[0x0d0a]

There is an Objective-C binding for Qt/KDE, it's just not finished, so it's not in the list. These bindings don't appear out of thin air, they need developers who use those languages to make them. If you have a favorite obscure language that needs Qt/KDE bindings, then get your ass on the ball and write some!

I'm already pretty comfortable using gtk+ -- I have a friend that likes KDE (and hence likes using Qt based apps), though. A number of times he's complained about no Qt bindings for a language, citing that as the reason for not wanting to donate code to a project. He isn't really interested in writing a set of bindings -- he wants to write application code.

This is taking it to the extreme. Some of those languages are obscure. Others are inappropriate lanaguages for GUI application development.

Some of them, yes. PHP and JavaScript is more cute than useful, and I have zero knowledge of Erlang, TOM and XBase, so I can't say anything about them. I suspect that the bindings don't conform beautifully to the Haskell language (though I expect there are a number of grateful Haskell programmers out there).

However, Ada, C++, Common Lisp, Eiffel (I've gotten interested in eiffel myself recently, as it has a tremendous number of attractive features, and can produce very fast compiled code), Guile, Java, Objective-C, Objective-Caml, Objective-Label, and Pascal are full-blown programming languages, and overlooking them is, it seems, not to be sneezed at. My friend likes Objective Camel more than any other language, and he cannot develop Qt apps with it. (Take a look at MLDonkey if you want an example of what can be done with gtk and ocaml.)

As for the classes I mentioned, I still feel that a large amount of Qt code is unnecessary in a modern toolkit, and makes interoperability with other libraries more frusterating. I realize that at the time they were added, there was a reason, but now they're a lot of baggage that gtk has avoided. And what really matters is what the developer gets today, not whether Trolltech was justified in their original decision.

The "small parts" philosophy of UNIX applies to applications, programs and utilities. It does not apply to libraries. Go check out libc for an example of another library that includes everything but the kitchen sink.

Libc is a special case -- minimizing dependencies and possible things to break in the runtime for the fundamental language for a platform has a significant amount of value. Too many basic utilities depend upon libc to make mix-n-matching with it safe.

Qt is a crossplatform application framework. It was written with a completely different set of goals than GTK+, which aimed to be just a widget toolkit.

That may certainly be true -- but at least for me (and apparently others -- Windows users using GIMP), gtk is quite cross platform, and more attractive. And that's really what matters, compred to the original design plans.

Now, Qt has a nice embedded target, but I'm not sure how useful crossplatformability is between a palmtop and my desktop, given the other limitations between the apps and the liklihood of a necessary UI redesign anyway.

Maybe you should get off the FSF bandwagon and join the Free Beer Foundation instead.

Am I on the FSF bandwagon? (Especially since I'm complaining about a company using the GPL instead of the LGPL here.) I have major issues with lots of Stallman proposals. I certainly don't approve of having him on the GNOME Foundation Board, for instance. But I don't really think having a private company control a core library is a great idea. If people want control over important aspects of modern UNIX systems, I think limiting that to apps and secondary libraries is reasonable. Qt is intended to be a core library, *the* widget set, by Trolltech -- and that's too much power for them to have.

Where does this rumor come from that C++ == Windows?

I didn't say that. However, the percentage of development done on Windows in C++ (relative to other languages germane to our discussion -- Visual Basic doesn't apply, since neither gtk nor Qt support it) versus the percentage done on UNIX in C++ is far higher. When you come out with a library that caters to one development community or another, you have to decide what market is most important to you. Trolltech emphasized C++, which is most popular on Windows. [shrug]