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."
Now, I know some people feel it's redundant to bring this up, but why does it cost so much to license Qt for commercial applications? I mean, I can buy Visual Studio for each of my developers for less than I can license Qt-X11. How does that encourage me to develop for Qt? What about shareware applications? Why not make Qt LGPL?
A solution to the problem with music today
I know it will cygwin but :
"With the release of Qt 3.1, customers who use Qt for Microsoft Windows development can now use Qt with ActiveX."
When can I expect a native KDE ?
Their html is weird too
<title>Trolltech - Title</title>
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
What is Slashdot doing promoting software written by trolls? It's pretty hypocritical, and it might give trolls the idea that they're welcome here. Editors, could you please cancel this story?
Karma: Good (despite my invention of the Karma: sig)
Maybe I should just go straight cvs...
Slashdot: Where people pretend to be twice as smart as they really are by behaving like children.
What's the status of the XFT support? I heard that was to be *the* new feature of 3.1, I didn't see it mentioned anywhere.
>I still think that Qt is easily the worst thing about KDE. It supports few languages (and only C++ well)
It supports Java, Perl, C#, Objective-C and Python. That covers most of the popular ones.
>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)
Gtk+ is actually quite slow and is as bloated as Qt. The speed difference is mainly in program startup and that is mostly to do with the linker.
>it fails to use the STL
You can use the STL within Qt from version 3 onwards.
>Qt lacks gtk's incredibly useful dynamic keybinding features
That has disappeared in GNOME 2.
>The licensing thing isn't as bad as it used to be, but it's still frusterating.
GPL is the recommended library licence as said by http://www.gnu.org/licenses/why-not-lgpl.html . It's only a problem if you want to write closed source software while freeloading on other peoples work.
Hah! Get a clue dude!
Qt supports a lot of languages. Sure, C++ is it's native and preferred language, but GTK+ has a native and preferred language to, known as C. Qt uses the STL. Complain to your package builders, because Trolltech didn't make them. Duh! And it's bigger because it does a heck of a lot more than widgets-only GTK+.
You don't think their widgets are attractive? Even when it has a native GTK+ widget theme (motif-plus)? Then go grab some others! Liquid, Keramik, Qinx, etc. Or write your own.
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
GTK+ is a business? It earns revenue? Wow! When did that happen? GTK+ manages with the LGPL because it is a free beer library.
A Government Is a Body of People, Usually Notably Ungoverned
...most of the popular ones...
Hmm, the KDE site doesn't list Objective-C as a language with bindings, but I'll take your word for it. That also screws over a lot of people who left Windows development precisely because of the massive reliability on C++. And as for those languages...Objective C and C# might be nice (haven't used either enough), but Java is too slow for general application use, and Perl and Python are scripting languages, not something you'd normally use to write a full-size app. Now, I admit that occasionally writing just a front end can be useful, but there isn't actually a lot of reasonable alternative presented there.
Gtk+ is actually quite slow and is as bloated as Qt.
I can say with certainty that this is not the case. Gtk+ apps are much snappier on my PII/266, and as for bloat -- Qt has *far* more extraneous features built into the thing. It isn't a widget set, it's a whole bloody platform.
You can use the STL within Qt from version 3 onwards
I haven't gone through Qt 3 -- was the API actually redone to support the STL fully? On the level that, say, gtkmm does? I'm rather dubious.
That [dynamic keybinding] has disappeared in GNOME 2.
This is not true, though apparently it now requires a minimal amount of effort on the application developer's part. See gtk-menu-set-accel-path() in the gtk2 documentation.
GPL is the recommended library license [as said by the FSF -- big surprise]...It's only a problem if you want to write closed source software while freeloading on other people's work.
Ah, thank you for clarifying that. I wasn't aware that FreeBSD, OpenSSH, XFree86, and other major projects were "closed source software" written by "freeloaders". Those BSD types sure are the antithesis of open source programmers.
May we never see th
After having read the previous comments I'd like to post a reply to all of you.
Trolltech is a company selling a cross platform library called Qt. It is freely available under GPL and QPL for the Unix/X11 platform. The licensing costs for other platforms are there since Trolltech tries to make money from their product.
Many claim the Qt is bloated. This is because they do not see what Qt is. Qt is not a UI toolkit, it is an entire cross platform toolkit. That is why it includes most problem areas: sockets, file system access, database access, UI and much more.
The next set of common complaints is concering the STL usage. From Qt 3.x you can use STL together with Qt. Qt does however provide its' own classes for text, values, etc. This is to provide better cross platform support, for example QString supports unicode on all platforms. The QList and other container classes contain useful extensions compared with the STL containers.
As for language dependence. In professional software development C++ is the most commonly used language and will be for quite some time. The other language bindings available are great for developers wanting to use other languages, but they do not render much (or any) revenues to trolltech and is thus not interesting.
The signal/slot architecture used in Qt is also a thing to complain about. What does it do? It makes the code more intuit and estetic. It also speeds up the development (no need to declare struct/classes to pass arguments). Qt provides good debugging support to find all the dynamic errors that can arise from this. The architecture is (now) well tested and proven to work.
To sum things up: 1) Qt is a cross platform toolkit, not only a UI toolkit, 2) Trolltech wants to make profit, noone forces them inte giving the open source community access to Qt, be grateful, 3) the signal/slot architecture works in real life even though it is not the optimal solution from a philosophical point of view.
All above is MHO. I do not mean to flame anyone!
Really? When did they lose the QString and QVector class and other ugly warts?
When all STL implementation are good, complete and compliant. IOW not in our lifetime.
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.
It's a shared library use the parts you need, forget the rest. The are losts of parts KDE doesnt use.
Not bad, but pretty lame that it can't even do a single functional language, much less Objective C.
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!
Note: Bindings for popular scripting languages is a plus. Qt supports the three most popular ones. It also supports the two most popular byte compiled languages. And since it supports C, you have your common denominator.
Gtk has [gtk.org] 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.
This is taking it to the extreme. Some of those languages are obscure. Others are inappropriate lanaguages for GUI application development.
GTK+/GNOME makes the mistake of trying to please all of the developers all of the time. When a developer says "give me Ocaml or go to hell", sometimes the best solution is to say "sure, go to hell." If you'll notice, GNOME does not include any Ocaml code in its core packages. If any developers submit some, GNOME would be correct to reject them. You do not want to burden the user with twenty different runtime libraries.
p.s. My goal is not to slam Ocaml. I am using it as an example only.
The Qt people evidently didn't see compatibility with less-used languages as important, so they snubbed everyone else.
When I publish documentation in English, I am not snubbing speakers of German, French or Cantonese. I publish my documentation in English because that is what I know. But I do not restrict translations. If you want my stuff in German, you have my blessings to go forth and translate.
Likewise, if you want Ocaml bindings for Qt/KDE, you have my blessings, along with Trolltech's, to go forth and bind.
Really? When did they lose the QString and QVector class and other ugly warts?
They did not lose them. But they made them STL compatible. That means you can use the STL instead of the QTL if you choose. Trolltech can't get rid of them now because some platforms and compilers still don't support the STL or modern templates. And the three major STL implementations are subtly different from each other, which plays havoc with a crossplatform library.
And besides which, while QVector may now be redundant, QString is not! QString has twenty times the power and flexibility of STL string.
"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.
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.
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.
And of course, it's a dynamic library, so your application only loads what it needs.
Qt is not a free beer library. And that's a sorry state of affairs.
No commercial software development is going to be profitable with free-beer as a product. The only choices in FOSS for profitable development libraries is to offer a hard-copyleft product, or offer a proprietary version for proprietary developers. Neither will be free-beer for proprietary developers. Maybe you should get off the FSF bandwagon and join the Free Beer Foundation instead.
The impression I got is that Qt pretty much exists to pander to ex-Windows types, who are used to coding in C++.
Where does this rumour come from that C++ == Windows? It's silly. C++ started out on UNIX. It was completed on UNIX. It was been used on UNIX since day one. Microsoft pushes Visual Basic more than Visual C++. It's now emphasizing C#. So why do people persist in equating C++ with Windows?
They only people Trolltech panders to are crossplatform application developers. Go read their 3.1 announcement. Half the stuff panders to crossplatform interests.
Trolltech chose C++ for Qt because a popular object oriented language is preferable for GUI and application development. C++ is by far the most popular object oriented language. It compiles into fast and efficient native code. They made the right choice.
A Government Is a Body of People, Usually Notably Ungoverned
> >Qt lacks gtk's incredibly useful dynamic keybinding features
> That has disappeared in GNOME 2.
And besides that, it DOES have dynamic keybinding, or at least it did in version 2.3. Haven't played with it recently. But I'm personally of the opinion that dynamic keybinding is a really bad idea. It's not at all intuitive to newbies, and even for experts, there's no feedback at all given as to what's happening, and there's no conflict resolution policy. Shouldn't I be *asked* first if I try to reassign Ctrl-C from "copy" to "close window" or something?
I don't know if Qt still has dynamic keybinding, but I hope they got wise and removed it, as it sounds like Gnome is doing as well.