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's licensing

[i_am_nitrogen]

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?

Re:Qt's licensing

[Yokaze]

Microsoft is a large software house and has various different sources of income. They are using Visual Studio in house. Furthermore they are profiting from binding developers to the Windows platform.
I can imagine, they could even distribute it for free.

The distribution of Qt/X11 under the GPL leads to a greater acceptance of Qt, while preserving the most lucrative market.

How can they earn money licensing it under the LGPL? Any commercial product could use Qt without paying a single penny.

Re:Qt's licensing

[fault0]

> Why not make Qt LGPL?

Hate to say this, but this applies here:

Keys to Trolltech's longterm financial stability:
1. Make Qt LGPL
2. Make dinner
3. ???
4. Profit!!

Re:Qt's licensing

[Uma Thurman]

The cost for Qt might seem high, but there's a couple things to consider:

1) You get a LOT for the few thousand dollars that you spend. What would it cost you to develop the same functionality and debug it in house? I'd bet it would be at least 100 times what they charge for a developer license.

2) The cost is low compared to what you will make from commercial software developed with Qt. Say you spend $20,000 on licenses for your entire team. That would be a fairly large team for most things - not everyone on the team will need a development license. If you've got a dozen developers and you're worried about not making back enough to cover the license cost, the the market is probably too small to cover the salaries of the programmers.

3) You get portability. New platforms, new markets. If you're making an enterprise application with a GUI, you don't want to restrict yourself to just Windows. UNIX is huge in enterprise applications, and your product should run on Windows or whatever UNIX your prospective customers want to run.

4) Shareware might benefit from another library. Qt isn't for everyone, and I don't think that Trolltech is really marketing their product for people who want to sell a few copies that run only on Windows. If you're in that situation, you'd be better going with something like wxWindows or any other library that supports just the platforms you want, and don't cost so much.

In a nutshell, this market has a number of tiers. Qt has targeted the high end of the market. There are other products that might be better suited for projects that don't fit into the categories of GPL software, high-cost/low volume, or low-cost/high volume commercial software that would justify choosing Qt. Ain't freedom of choice wonderful?

Re:Qt's licensing

[Arandir]

Qt versus VS: No comparison! They're completely different creatures. One is a crossplatform library, the other is Windows only. One is quality, the other crap. One is a full application framework, the other is a compiler with a few OS headers and wizards. One has a clean OO architecture, the other is chock full of unreadable macros.

What about shareware? If one shareware developer can't generate enough revenue to cover $1500, then it's time to look for a better business model. Geez!

Why not LGPL? Because Qt is of such high quality that no one needs support. If you make the product free-beer, where is the revenue going to come from? Trolltech isn't a charity. It's a business. It needs to generate revenue to stay in business. The only FOSS libraries making revenue are those that require support.

Re:Qt's licensing

[chrisseaton]

You get all that with wx and it's GPL.

KDE on Windows, when?

[DrSkwid]

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>

Re:KDE on Windows, when?

[Arandir]

When can I expect a [Windows] native KDE?

When Windows becomes a UNIX. Until then the effort spent porting to an archaic architecture isn't worth it.

Re:KDE on Windows, when?

[DrSkwid]

It's already posix compliant.

The point i was making is that QT claims to be a cross platform dev environment of which KDE is the flagship so the natural step should be cross platform KDE. I was also being ironic in that KDE is oft accused of Windows cloniness.

It's not really a product I want. Would be nice to see it live but I don;t have any expectations.

I'm an Enlightenment and plan9 user anyway. I like my desktops empty not crammed with silly little pictures.

Re:KDE on Windows, when?

[Arandir]

It's already posix compliant.

I've heard that before, but I still find it silly. There are several levels to the POSIX standards, and NT/XP meet only a few of them.

The point i was making is that QT claims to be a cross platform dev environment of which KDE is the flagship so the natural step should be cross platform KDE.

Qt does more than claim, it IS an crossplatform development environment. It's the best I have every seen. But KDE requires more than Qt. It also requires X11, since some display stuff appropriate for a desktop is not appropriate for a widget library. It also assumes a POSIX and UNIX infrastructure.

Some stuff could be ported relatively easily though. Other stuff would be impossible or would need to be rewritten from scratch. Most stuff would be inbetween, and difficult but not impossible. I can envision a Konqueror port. I cannot envision a KWin or Kicker port.

I'm an Enlightenment and plan9 user anyway. I like my desktops empty not crammed with silly little pictures.

Last time I used Enlightenment, it had more silly little pictures than KDE ever dreamed of. Of course you can make Enlightenment as bare as plan9, but you can also make KDE equally spartan.

what the heck?

[tps12]

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?

Re:what the heck?

[ivanandre]

What an idiot... o.k. it may seems funny sometimes... but this is old

Damn.

[GreyWolf3000]

I just spent an hour last night building qt-3.1.0-beta2, only to realize I needed rc3 in the kde directory, only to realize today that 3.1.0 final is out.

Maybe I should just go straight cvs...

Xft support?

[Ashish Kulkarni]

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.

Re:Xft support?

[IIEFreeMan]

It's mentionned on the 3.1b1 Changelog near the end.

Re:Xft support?

[fault0]

Qt has supported Xft since Qt 2.3.0. There were patches made by Keith Packard for Qt 2.2.x.

Qt 3.1 is the first with Xft2 support.

[YAWN]

[Anonymous Coward]

No more comment - that's it. BFD.

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

[Anonymous Coward]

>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.

Re:Qt slow, annoying

[Arandir]

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.

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]

...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.

Re:Qt slow, annoying

[Anonymous Coward]

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.

Perl and Python are good enough to write full sized apps. But you are right that there needs to be more bindings, especially for lisp and other functional languages. C++ helps autogeneration of bindings for object orientated languages, but I guess it's difficult fitting it nicely into a non OO language. Oh, I think there are also javascript bindings (coming) from trolltech. But that is for scripting, not building apps.

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.

App running speed should be similar, app startup speed should favour Gtk+. Running speed may differ if say Qt has AA enabled and Gtk+ doesn't. The app startup speed will be solved by a new linker, but it is not finished yet. Also, Gtk+ seems to be going in the same direction as Qt as far as features go. Most of the higher level bits of code that were in GNOME libraries are now being moved slowly into Gtk+.

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.

It fully supports the STL but keeps the old way of doing signal/slots using moc.

This [lack of dynamic keybinding] 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.

Well that's good to hear, but I think it will slowly be phased out because it causes too much confusion with newbies.

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.

I'm not sure you see my point. No one has a problem with writing software against a GPL lib, unless you are writing non free software. Okay, you may choose an opensource licence incompatible with the GPL, but then you could pick the QPL licence instead. The fact that you have to pay to make closed source software with Qt is only a problem for people who want to do that without paying any money.

Re:Qt slow, annoying

[Isle]

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.

Re:Qt slow, annoying

[Anonymous Coward]

I believe that QT is the best GUI toolkit, esp. because of its good documentation. What I would like to see is QT as the standard GUI Toolkit for Java.

Re:Qt slow, annoying

[Arandir]

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.

Re:Qt slow, annoying

[Arandir]

That also screws over a lot of people who left Windows development precisely because of the massive reliability on C++.

The people who left Windows solely because of C++ can be counted on one hand. If you don't like the MFC, use straight Win32 with C instead. Duh! Or use Java, Perl, Python, Lisp, etc. I even hear you can use Miguel's favorite byte-code language!

People leave Windows for much more substantial reasons than Visual Studio including C++ along with C, C# and VBasic.

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]

Re:Qt slow, annoying

[WWE-TicK]

> 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.

Who told you this? Perhaps on Linux, this may be true (the lack of a mature C++ compiler for so long may be a possible explanation for this). But Linux is hardly representative of UNIX in general.

Re:Qt slow, annoying

[baxissimo]

> >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.

Qt developers must be killed !

[Anonymous Coward]

Where the fuck is CVS and why do I have to get patches made by Xdelta ? I want to patch my sources, not create a new tarball and untar it again.

Ironic that GPL now favored by commercial vendors

[Anonymous Coward]

The software landscape has changed in the last 10 years. Who would have believed a decade ago that commercial software vendors would embrace the GPL while selling the same software commercially? It's so crazy - it just might work!

What Qt is...

[e8johan]

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!

Re:What Qt is...

[Anonymous Coward]

Qt is bloated.
I just LOVE 5 meg DLL/SO files.

Even when I use Qt I have to have '#ifdef WINDOWS'!
Something is fucked up and Qt is only a bandaid.
Qt exists because M$ is brain dead. It's an abstraction of programming to make Windows, Linux, Mac OS X play nice. That's great, but why not fix the original problem?

Where'd C's 98% portability go? Bring it back God dammit!

Qt 3.1 - Paving the way to virii?

[nighty5]

I just noticed QT Script for Application being an addition in Qt 3.1 to the already highly successful and feature rich toolkit offering.

This will probably provide inroads to create easily scripted trojans, virus's in QT applications?

Also with linking support for Active X within the QT suite, it sure sounds like a cocktail of fun for would-be viruses.

Look out KMail!