×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

QT 4.5 Released, Plus New IDE and Analysis Tool

timothy posted more than 5 years ago | from the cute-train-is-the-q-train dept.

Programming 62

stoolpigeon writes "QT 4.5 has arrived and is now available for download. This new release is quite significant due to licensing changes that now make it simpler to use QT in a wider range of products without cost as well as a number of new features. The latest version of Webkit is now integrated into the product. Qt 4.5 sees the introduction of QtBenchLib, a new component to make measuring the performance of the toolkit and checking for regressions easier. Mac developers who use Qt will note a major reworking of 4.5 on the Mac, now providing 64-bit support. QT Creator is a new IDE that looks to have combined a number of previously separate tools. And there is much more."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

62 comments

Excellent! QuickTime from Apple (2, Funny)

Anonymous Coward | more than 5 years ago | (#27051853)

Excellent. QuickTime from Apple is a great media viewer and I'm excited to see a new version released.
Interesting that there's nothing on the www.apple.com website about it... hmm... it must be released "on the QT" ( http://en.wiktionary.org/wiki/qt?rdfrom=QT )

Re:Excellent! QuickTime from Apple (0)

Anonymous Coward | more than 5 years ago | (#27051957)

Apple fanboy FAIL

Re:Excellent! QuickTime from Apple (4, Informative)

c_g_hills (110430) | more than 5 years ago | (#27057105)

Actually, editor fail. The article is referring to Qt - not QT.

Re:Excellent! QuickTime from Apple (1)

nawcom (941663) | more than 5 years ago | (#27060685)

Actually, editor fail. The article is referring to Qt - not QT.

You know, if you look at the posts below you will see people still think it's some acronym, QT. This reminds me of people who are "Lie-nicks" professionals and think they know what "day-mons" are. And if you do point these out to them, they will acknowledge it, but still call it QT. "What does the QT stand for?" "I dunno."

Well I'm done with ranting. There's just this small thread of ignorance in IT, that will never put forth effort into listening what the creators have to say about pronunciation of their own products.

Re:Excellent! QuickTime from Apple (0)

Anonymous Coward | more than 5 years ago | (#27083029)

It's not spelt like "linnux", it's spelt like "Linus", hence the correct American* pronunciation is "lie-nucks". Alas, only people who were using Linux before the turn of the century seem to know this. When Linux started to get a little popular, some typical dumbass journalist found out about it and fucked up the pronunciation, and then all you kiddies who came later only knew it by the popular, ignorant mispronunciation. So now we're stuck with it. Kind of like how "hacker" meant nothing to do with breaking into things, when the term was used back when I was a CS student in the late 80's/early 90's, it only meant someone who jumped right into coding without doing much or any design or thought first. We have another dumb, lazy journalist to thank for mixing this up and then it sticking among the clueless masses, too.

*And Torvalds pronounces his name sounding like "lee-", so if you don't want the Americanized pronunciation the OS's name would sound like "lee-nucks". Either way, there's absolutely no reason it should be "lin-nucks". Except that that's what everybody thinks it is these days.

Re:Excellent! QuickTime from Apple (1)

rusl (1255318) | more than 5 years ago | (#27114619)

I'd say you're the one who fails to see the ultra subtle sarcasm here. Triple puns! QT Qt Q.T.

Or maybe you are being sarcastic with your FAIL as well? So deeeeep.

Ah, if only emoticons weren't so lame... text just doesn't convey tone of voice.

Nice (2, Interesting)

Anonymous Coward | more than 5 years ago | (#27051873)

Qt is the most sensible C++ library I've ever used. And its sensibility reaches from string handling to the build process.

It allows you to untangle the mess that raw C++ is, and actually use the power.

Re:Nice (0)

Anonymous Coward | more than 5 years ago | (#27053505)

C++ without templates and mixins is far less powerful. It's appalling how little of the language moc actually supports. And unportable assumptions are always a plus (signals and slots don't even work unless your compiler is lame enough to always use vtables for everything).

Re:Nice (1)

Carewolf (581105) | more than 5 years ago | (#27054299)

Separate interfaces and implementation then. Signals and slot are interface tools, templates are implementation tools. Yes you can mix that in C++ but it's usually not a good idea. Even is you disagree, nothing is really lost, except the ability to combine two great tools, and you can't really complain that the power drill doesn't make the chainsaw easier to use.

Re:Nice (0)

Anonymous Coward | more than 5 years ago | (#27114627)

Templates are an interface tool. There's nothing there people didn't do before using big macros, except that approach was so awful to interact with. If none of the important objects (the ones actually callable via Qt) can use or be template types, you've be better off in Java, because that language is correctly designed to be Objects For Dummies.

From native to web (4, Informative)

arendjr (673589) | more than 5 years ago | (#27051979)

In a world that's moving fast from native application to web-based applications, I believe their bet in integrating WebKit is an excellent choice.

At my company (a web company) we had to choose a platform for our native client and basically the choice boiled down to Mozilla's XUL platform, Adobe AIR and (just in time) Qt with WebKit. We decided for the latter and do not regret it!

While QtWebKit has a lot of rough edges in Qt 4.4, I believe there is a *lot* of potential, especially given the huge improvements they made in that area in Qt 4.5. JavaScript has seen a huge speed bump due to the SquirrelFish engine, you can expose C++ objects to JavaScript (already in 4.4), and with some work you can even connect native Qt signals to JavaScript methods, there now is support for HTML5 and CSS3 transformations. Without exaggeration, this really is the best of both worlds.

And now with the LGPL license option it's even available to about everyone who wants it. Good job!

Re:From native to web (3, Interesting)

Anonymous Coward | more than 5 years ago | (#27052603)

I dont get it, how do you port native code to the web? does it compile to some kind of html+js? or is it just using web stuff directly in the widgets of a native app?

Re:From native to web (4, Informative)

arendjr (673589) | more than 5 years ago | (#27052887)

It's the latter. You can just use web controls as part of a native application. Basically you can just create a native application window, and render its entire contents using HTML/CSS. Or just a part of the window if you like. And all JavaScript code in those web parts can just call back to your native code where needed.

And the other way around is also possible. You can embed native controls into your web view just like how you embed a Flash object into a web page. And again, there's no problem in communicating between native code and JavaScript. Though if you want to pass complex data structures you will likely want to pass those as JSON objects (which in turn can be easily mapped to and from QVariantMaps, if you Google around you will find plenty solutions for that).

Re:From native to web (1)

Cyberax (705495) | more than 5 years ago | (#27053915)

There's also a nice project called HTMLayout - it's a VERY lightweight HTML engine with support for native widgets and rich CSS styling (far far better than in QT).

It would be nice to see it integrated with QT one day :)

Re:From native to web (1)

pembo13 (770295) | more than 5 years ago | (#27054587)

I am very much not a fan of this move to web based everything. I like having web interfaces to things. But I hate only having web interfaces. Even more I hate the idea that one day I may have none of my own data on my own machine. Having the option is fine, but that option seems to be slowly disappearing.

Re:From native to web (1)

Midnight Thunder (17205) | more than 5 years ago | (#27054613)

In a world that's moving fast from native application to web-based applications, I believe their bet in integrating WebKit is an excellent choice.

WebKit certainly has the benefit of having many more people contributing to its development. KHTML was the start, but for better or for worse WebKit is where it is at.

BTW When will Konquerer make use of WebKit?

Re:From native to web (1)

Joe Tie. (567096) | more than 5 years ago | (#27058485)

The webkit kpart is, I'd say, something like 98% usable now. I don't use konq all that much, but it's in a solid enough state that I've set webkit as the default for rendering webpages.

Re:From native to web - Wt (1)

paugq (443696) | more than 5 years ago | (#27058069)

If you like C++ and the Qt API and you want to develop for the web (true web 2.0 AJAX apps), you should try Wt [webtoolkit.eu].

Wt clones the Qt API but using Boost instead of Qt. You can compile your web application to a FastCGI module (which you can deploy with Apache, lighttpd, IIS, etc) or to an executable which includes an embedded HTTP(S) web server.

Oh, and there are Ruby bindings [fosdem.org], too (code [github.com])

Oh, and best of all: you can link to any C and C++ library (including Qt). No more messing with Ruby/Python/PHP/whatever bindings!

LGPL (0, Redundant)

zebslash (1107957) | more than 5 years ago | (#27051999)

The news does not mention that very importantly it is now provided under a third license, the LGPL. That will allow small companies to link the library in their proprietary products (for the best and the worse...) Certainly that should increase the use of Qt and probably decrease wxWindows usage at the same time.

Re:LGPL (3, Informative)

stoolpigeon (454276) | more than 5 years ago | (#27052161)

This new release is quite significant due to licensing changes that now make it simpler to use QT in a wider range of products...
 
fully spelled out in the linked article.

Re:LGPL (1)

larry bagina (561269) | more than 5 years ago | (#27052291)

going LGPL is a very good step with no downside for the open source community. Previously, if a company wanted to release a closed QT app, they paid for the proprietary license and released their closed source app with a closed source QT. Now, they can still release their closed source app, BUT the QT part will still be LGPL so users can replace it if they need to. (And if they make any changes to QT, they'll be FOSS)

Fact is, GPL can (and is) used as a tool to push non-FREE licenses on dual-licensed software. The LGPL is better in that respect.

Re:LGPL (4, Insightful)

nedlohs (1335013) | more than 5 years ago | (#27052327)

You mean other than in the first fucking paragraph.

You know the paragraph that is about nothing except the addition of LGPL to the licenses.

Re:LGPL (2, Insightful)

0racle (667029) | more than 5 years ago | (#27052415)

The actual news item a little while ago about that change wasn't enough? For how long does it have to be mentioned every time QT is?

WebKit support and Acid 3 (2, Informative)

MrHanky (141717) | more than 5 years ago | (#27052059)

Using Qt 4.5-rc1 from Debian Experimental and the Arora browser [google.com], I get 98/100 on Acid 3. It renders pretty fast as well.

Re:WebKit support and Acid 3 (2, Informative)

IceFox (18179) | more than 5 years ago | (#27052391)

After the rc was released the last fixes went in so 4.5.0 QtWebKit gets 100/100 on the acid3 test.

Re:WebKit support and Acid 3 (2, Informative)

ardor (673957) | more than 5 years ago | (#27062373)

99/100 here, using the official 4.5 release. Apparently, the link test fails.

Jambi (Qt for Java) discontinued (4, Informative)

Maxwell42 (594898) | more than 5 years ago | (#27052453)

And for those like me who were quite excited with the new licensing and wanted to use it with java... Don't think of it...

Qt Jambi - a port of Qt to the Java programming language - has been discontinued in order to focus resources on the Qt cross platform application and UI framework. Qt Jambi will be maintained for one year after the March 2009 release of Qt Jambi 4.5.0_01, and will be made available upon release under the LGPL license

QT Programming Language Support [qtsoftware.com]

Re:Jambi (Qt for Java) discontinued (2, Insightful)

zebslash (1107957) | more than 5 years ago | (#27052539)

Well, you forgot to paste the next paragraph:

To help faciliate the continued development of Qt Jambi, Qt Software will host and help maintain a community-driven Qt Jambi implementation.

So it is not completely ditched, it relies on the community to maintain it.

Re:Jambi (Qt for Java) discontinued (1)

Maxwell42 (594898) | more than 5 years ago | (#27052751)

We'll see in the long term if there are people willing to maintain it...

Re:Jambi (Qt for Java) discontinued (2, Interesting)

Carewolf (581105) | more than 5 years ago | (#27054335)

PyQt and several other Qt-bindings are community maintained, and I think there are more Java users in the world than the Python users. I could be wrong though, or the Java users could all be corporate slaves and not interested in free software development. Still I would put my money on Jambi surviving.

Re:Jambi (Qt for Java) discontinued (3, Informative)

pembo13 (770295) | more than 5 years ago | (#27054667)

PyQt is also currently in the middle of nowhere. And PyQt, as far as I can tell, isn't really community maintained. Its a very small group of guys doing all the work, and who as of yet haven't come to a decision on what will happen to the project now that the little revenue they got from commercial licensing will likely dry up.

I was hoping that Qt would actual pull in more projects and not drop them.

Re:Jambi (Qt for Java) discontinued (2, Informative)

Simon (815) | more than 5 years ago | (#27055371)

PyQt is developed as a commercial product which is available under a closed source license and under the GPL plus the other FOSS licenses that Qt itself used before the recent change to LGPL.

--
Simon

Re:Jambi (Qt for Java) discontinued (2, Interesting)

ChunderDownunder (709234) | more than 5 years ago | (#27058047)

It's a very small niche. I suspect the reason for the 'community-driven' spin-off is that Jambi has received a lukewarm response from commercial developers (who, until now, haven't had the benefit of LGPL).

Java has an extensive range of established frameworks and for UI toolkits Swing and SWT. I, and evidently Nokia, can't see the business case for adopting Jambi. Ignoring the technical details, it's much easier to assemble a team of experienced Swing developers.

I'm a Java developer by trade. If a project I worked on made the decision to use a Qt based frontend, I'd be inclined to back the mature C++ version (rather than an unsupported side-project), while using Java EE on the server as necessary.

Beware the Java-Cocoa experiment on OS X. Sorry to spread FUD but I think the community project will be limited to hobbyists only.

Re:Jambi (Qt for Java) discontinued (1)

theolein (316044) | more than 5 years ago | (#27058831)

Wish I could mod you up. This desire to just write in any language, be it javascript, php or C++ and then mix it all togther in one project is not a good thing, imho. It's brought forward a generation of "coders" who never learned the basics of software engineering and write software that reflects that lack.

Re:Jambi (Qt for Java) discontinued (1)

Prien715 (251944) | more than 5 years ago | (#27056759)

The guys at Qt don't have an infinite budget.

Some of the ideas work really well and are adopted in the marketplace (Qt's Designer), but others (like Jambi) die because no one uses them. It's natural and healthy. Besides, if anyone really does find it useful and wants to use it and extend it, Qt has left the license in such a way as to say "Go for it!"

Jambi's changing status, I think, is due to Java's evolution as THE backend language for server heavy processing things like databases (Oracle) or massively parallel scientific computations. At the same time, Java isn't used for graphical applications nearly as much as it was back in say '99.

Jambi tried to solve the problem with Java (namely the UI libraries are terrible), but maybe it was too late?

Re:Jambi (Qt for Java) discontinued (1)

Simon (815) | more than 5 years ago | (#27057267)

Jambi's changing status, I think, is due to Java's evolution as THE backend language for server heavy processing things like databases (Oracle) or massively parallel scientific computations. At the same time, Java isn't used for graphical applications nearly as much as it was back in say '99.

Jambi tried to solve the problem with Java (namely the UI libraries are terrible), but maybe it was too late?

I don't think that is really the case. I remember being at a Java conference for work once and there being a show of hands. Half of the developers attending were server side (and web), and other client side.

The main reason why Jambi probably didn't catch on, IMHO, is that Swing is standard in Java and is much much more established, regardless of its flaws.

--
Simon

Re:Jambi (Qt for Java) discontinued (1)

try_anything (880404) | more than 5 years ago | (#27073261)

Jambi tried to solve the problem with Java (namely the UI libraries are terrible), but maybe it was too late?

It's far from an abandoned space. Jambi/Qt faces the opposite problem: trying to take market share away from two large, popular GUI application frameworks: Netbeans and Eclipse RCP. Eclipse RCP is already well-established as the platform of choice for Java programmers who want to build GUI applications using native widgets. GUI applications framework have a significant learning curve, so the uptake of Jambi/Qt among Java programmers will be gradual at best.

As the developer of a commercial Eclipse RCP application, I'll be disappointed if Jambi doesn't catch on. It seems like a simpler, light alternative to Eclipse and a good choice when you don't intend to build a heavy, complex application (which is what Eclipse RCP is good for, and not much else.)

The question for users (-1, Flamebait)

drinkypoo (153816) | more than 5 years ago | (#27052513)

Is whether this release unfucks the whole thing, as KDE 3.5 did, or was this release number applied to make people feel like it did, to get them using the new system so that it can be debugged?

Re:The question for users (3, Insightful)

Abreu (173023) | more than 5 years ago | (#27052829)

You are confusing QT with KDE

Re:The question for users (0)

Anonymous Coward | more than 5 years ago | (#27054161)

You are confusing QT with Qt

Re:The question for users (0)

Anonymous Coward | more than 5 years ago | (#27057629)

You are confusing interesting with redundant.

Re:The question for users (0)

Anonymous Coward | more than 5 years ago | (#27076321)

Oh, the irony in your signature...

Awesome (5, Interesting)

sjones130 (1491221) | more than 5 years ago | (#27052565)

This is great. I was a GTK+ advocate back in '05. I recently changed over to QT4 (this past weekend infact) and I kept saying to myself "This really needs a good IDE, something like VS".. and here it is. This saves me having to use Eclipse (which I can't stand). woot!

Re:Awesome (4, Interesting)

HatofPig (904660) | more than 5 years ago | (#27057045)

You really need to keep your eye on KDevelop 4.0 then. Check out one of the main developer's blogs [wordpress.com] for tons of screenshots. It's a complete rewrite from 3.5 that takes advantage of just about everything KDE and Qt have to offer. I'm sure it is going to blow every other Qt/KDE IDE out of the water.

GCC 3.4.5 (2, Informative)

PhrostyMcByte (589271) | more than 5 years ago | (#27053315)

Wow, blast from the past with errors compiling standard C++ I haven't had to worry about for a long time. The Windows bundle package comes with MinGW GCC 3.4.5 built in January 2006. TDM's GCC builds [tdragon.net] to the rescue!

Re:GCC 3.4.5 (0)

Anonymous Coward | more than 5 years ago | (#27105851)

Downloaded and installed the latest TDM's GCC build. The project compiles, the app works, but now I have 114 build issues in the Qt Creator. There used to be none with the MinGW bundle. Is this normal?

PyQT4 - plans to change to LGPL too? (1)

sricetx (806767) | more than 5 years ago | (#27053381)

Does anyone know if there are plans to offer the LGPL licensing option for PyQT Python bindings? Typically they have followed QT licensing, but I could see that it wouldn't necessarily be in their best interest to offer LGPL. Of course, if they don't someone could just fork it and put them out of business anyway...

Re:PyQT4 - plans to change to LGPL too? (1)

wowbagger (69688) | more than 5 years ago | (#27053713)

I'd asked Riverbank that very question. I was told they were evaluating it, but would make no commitments either way just yet.

So, at least they are thinking about it.

Re:PyQT4 - plans to change to LGPL too? (0)

Anonymous Coward | more than 5 years ago | (#27053905)

Meanwhile, C#, Ruby and PHP bindings are LGPL already.

Re:PyQT4 - plans to change to LGPL too? (0)

Anonymous Coward | more than 5 years ago | (#27054375)

PyQt can't be forked to make it LGPL obviously but someone can create new bindings and I'm sure that many people would prefer them over non-LGPL'ed PyQt. Worst thing PyQt people can do is delaying the license change until a serious contender is formed. That would harm the community and waste efforts.

Re:PyQT4 - plans to change to LGPL too? (1)

pembo13 (770295) | more than 5 years ago | (#27054705)

The people in charge have not yet commented. And I was just getting interested in Jambi as well. But Qt is dropping it to the community.

Re:PyQT4 - plans to change to LGPL too? (1)

jonbryce (703250) | more than 5 years ago | (#27057833)

You can't fork GPL code into an LGPL licence. If you want LGPL code and the original developer doesn't agree, you will have to rewrite it from scratch.

QT ftw (2, Informative)

sapelko (1281580) | more than 5 years ago | (#27054021)

As much as I like gtk+ and gnome apps better, I've been using QT for a while and it really is a joy to use, years ahead of any other toolkit in terms of features and elegance

Re:QT ftw (0)

Anonymous Coward | more than 5 years ago | (#27054683)

As much as I like gtk+ and gnome apps better, I've been using QT for a while and it really is a joy to use, years ahead of any other toolkit in terms of features and elegance

Now all that's needed is a nice desktop environment* and applications to make use of it.



*nice desktop environment does not equal "look at the shiny buggy eye-candy and desktop widgets!"

SQL Stored Procedures (0)

Anonymous Coward | more than 5 years ago | (#27054513)

I would like to be able to call SQL stored procedures. Thanks for listening.

Re: (1)

clint999 (1277046) | more than 5 years ago | (#27059309)

Is whether this release un****s the whole thing, as KDE 3.5 did, or was this release number applied to make people feel like it did, to get them using the new system so that it can be debugged?

Guess how they added 64bit support to OS X? (1, Interesting)

Ilgaz (86384) | more than 5 years ago | (#27062737)

Qt is now Cocoa, that is how they added 64bit support. They already had plans for Cocoa but Apple's move as ''If you want 64bit GUI, you need Cocoa'' made them move faster. That is how Apple pushes developers I guess.

It is huge news for OS X, both Developers and Users. Imagine Cocoa Opera, Google Earth, Skype etc. and even the entire KDE 4.

While there was a lot of FUD against Carbon I don't agree, I guess a Cocoa based Qt will end a lot of bad feedback about Qt based apps on OS X, especially text rendering? I think Opera will be the obvious application we would see changes once they adopt it. Hopefully they will move as early as version 10 (which is in alpha now). I was blaming CmdrTaco upgraded to Web 2.0 ;) but it seems Opera spends a lot of CPU time in text rendering, not Javascript.

If a real developer enlightened us about what would change when Carbon to Cocoa transition happens, it would be better of course.

QT Creator and Python? (1)

nurb432 (527695) | more than 5 years ago | (#27070255)

Is it still tied to C++ like in the previews or are they supporting other languages/bindings now?

Check for New Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...