Qt 4 Beta 1 Available for Download

scc writes "Get it here. Trolltech's press release gives the details, including the projected release date: late first quarter 2005. Qt is the cross-platform GUI framework at the heart of KDE. At the same time, Trolltech released under the GPL Qtopia 2.1, an implementation of their GUI framework for Linux-based PDAs."

Comments

Re:QT

[Anonymous Coward]

Please think before you post...

What is the idea behind providing Open Source (GNU GPL) versions of Trolltech products?

They are our contribution to the open source software community. Part of our commitment is to enable those who contribute to open source software to receive something back. We also benefit, as open source software users contribute to the quality of the Qt product by providing bug reports and feedback.

Qt saved C++

[Anonymous Coward]

Qt has done more for C++ than any other single project. Kudos to the Trolls.

Re:Don't forget

[Corbin Dallas]

It costs a lot of money to develop commercial software with Qt (and by extension KDE) because they use the full GPL license (as opposed to something more reasonable like the LGPL) for the Qt library to extort money from developers. Trolltech effectively control any possible commercial software market for KDE (or anything that uses Qt).

So what if you have to buy a licence for commercial development? If you're out to make money on your software then you deserve to pay. Show me another cross-platform development suite as flexable and powerful as Qt that's free. Go on, I'll wait right here till you get back.

But naturally, Trolltech are benign lovable types, aren't they? Sure they are... except they are part-owned by SCO and Canopy -- the Linux IP grab and sue specialists. Avoid Qt. It's poisonous to free software.

If you're going to troll, at least take the time to write something with fewer holes in it. Trolltech is partially owned by Canopy but not SCO. Big deal. If you were to discover that the Unibomber owned 5% of Nabisco, would you really avoid eating thier crackers? Qt ( and Trolltech ) are great friends to FOSS.

Qt beats Java/Swing hands down

[Anonymous Coward]

Having programmed in both Qt/C++ and Java/Swing for several years I can say that Qt kicks Swing's butt for ease of programming, speed and simply a better looking interface. The subset of C++ that Qt employs can be quickly mastered by any programmer - professional or novice. KDE is proof of that. When you are thinking about a cross-platform GUI think twice before going with Swing. It may be free - but you get exactly what you pay for.

Re:more info here

[karstux]

I'd rather have broken backwards compatibility than eternal stagnation: in the computer world, that's usually the price of progress.

Also, what's stopping you to distribute the Qt2 or Qt3 libraries with your program? Yes, it probably bloats the package, but the possibility is there.

Re:No Free Windows Version

[rjstanford]

The whole point of Qt is to make it easier to have software run on multiple OS's, but I can't test any of my stuff on Windows. Oh well, still kick ass software.

Actually, the whole point of Qt from the perspective of TrollTech is to make money to feed their families (and, I guess, to allow them to buy US$50,000 kittens if they so choose). Providing free Mac/Linux implementations was a strategic business decision towards that goal.

Note: I'm a big Qt fan, and this should be taken as an endorsement rather than criticism. Better yet, it should probably just be ignored.

Re:Don't forget

[twener]

Don't forget that it costs a lot of money to develop Qt with this quality.

Re:I don't intend to start a flame war!

[Stevyn]

I personally think it looks nicer. That's subjective, of course. And that's not to say it looks more like windows. There is a "Ximian version" of openoffice available which can incorporate Qt widgets. It makes the interface much nicer. Some credit goes to the KDE folks though.

if only GUI libraries were really multithreaded

[CoughDropAddict]

I hear QT is good stuff. This isn't a slam on QT in particular.

However, I'm still waiting for the day when mainstream GUI libraries catch up to where BeOS was ten years ago, and put drawing in a separate thread from everything else.

There is absolutely no reason why GUI applications need to become sluggish when they are doing something computationally intensive. There's no reason that an application should stop posting redraws every time it makes a blocking call (like, for example, doing file i/o).

My eyes were opened to this shortcoming of "modern" GUI libraries by an entry in Bram's diary a while ago.

Re:if only GUI libraries were really multithreaded

[RdsArts]

Nothing against the opinion, I shared it for a time, but it's not really the problem that needs to be solved. Threading is not a magic bullet. In fact, most modern UI toolkits are rather well designed in this respect if the coder knows what they're doing.

But, let's assume you put everything in 2 threads, drawing and logic for ease of discussion.

The drawing thread, at best, will be the same as always because all you logic goes faster than it's refresh time. If not, it redraws when only half a layout is done, or when things aren't in their full initialized state. You can also kiss nice, clean, resizing widgets goodbye; you've just made it so each widget appears the minute you add it to a toplevel widget with the logic thread taking all the CPU time still.

By now, I'm sure someone is saying, "well, let's just toss a lock in there so we can stop that!" Yep, we've just done all that threading work for nothing.

Plus we still haven't made them any LESS sluggish. Threading it doesn't make the CPU usage go away, in fact it could worsen it because now we're seeing updates while the CPU is taxed (which you just know will look ever so crisp and quick). A sluggish UI is a symptom of a deeper problem than the UI's threading model, unfortunately.

A bester fix would be to put the heavy logic into a seperate "logic" thread, add some timeouts in the logic thread so it's not so insistant on hitting the CPU hard, and put all the end results into a bit of shared memory that a idle handler can then pull in when the UI is... well, idle. ;)

Re:Ignoring reality

[m50d]

Qt is truly free. It's GPL, GPL, GPL. If you're not happy with them also providing a propriety/commercial version, then you can fork the GPL version and release it only under GPL. Go on. Find enough people who really think it isn't free enough as-is, and fork it. Trolltech wrote most of Qt and they're the ones who get paid when people buy it, exactly like MySQL etc.

As for Qt being doomed, having programmed with Qt and the alternatives I could find, I don't think so. Qt is still much, much nicer to program with than GTK, especially since you now have to implement your own confirmation dialog box. Wx is getting there but still a nightmare to install (IME of course) and working through GTK rather than natively hurts it. As for SDL, it's great for 3d renderers etc, but would you seriously want to write a word processor (for example) with SDL widgets? I'm not sure where eclipse comes in, I thought that was a java IDE, in which case Qt is still the best toolkit to use with java on linux, IME, it's much faster than swing and fits in with the most popular desktop environment.

Re:Ignoring reality

[WWE-TicK]

Well then his post makes even less sense, you stupid anonymous jackass.

He says "working through GTK rather than natively hurts it". There is no "native" toolkit on X. Unless you're talking about raw Xlib or perhaps Athena since thats the widget set that actually comes with X. I can't imagine having wxWindows wrap Athena being any better than wrapping GTK, and if you want it to use Xlib directly theres the wxUniversal port.