Slashdot Mirror

← Back to Stories (view on slashdot.org)

QT 4.5 Released, Plus New IDE and Analysis Tool

Posted by timothy on from the cute-train-is-the-q-train dept.

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

47 of 62 comments (clear)

  1. Excellent! QuickTime from Apple by Anonymous Coward · · Score: 2, Funny

    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 )

  2. Nice by Anonymous Coward · · Score: 2, Interesting

    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.

    1. Re:Nice by Carewolf · · Score: 1

      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.

  3. From native to web by arendjr · · Score: 4, Informative

    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!

    1. Re:From native to web by Anonymous Coward · · Score: 3, Interesting

      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?

    2. Re:From native to web by arendjr · · Score: 4, Informative

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

    3. Re:From native to web by Cyberax · · Score: 1

      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 :)

    4. Re:From native to web by pembo13 · · Score: 1

      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.

      --
      "Thanks for all the money you paid to us. We've used it to buy off ISO among other things" -Microsoft
    5. Re:From native to web by Midnight+Thunder · · Score: 1

      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?

      --
      Jumpstart the tartan drive.
    6. Re:From native to web by Joe+Tie. · · Score: 1

      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.

      --
      Everything will be taken away from you.
  4. WebKit support and Acid 3 by MrHanky · · Score: 2, Informative

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

    1. Re:WebKit support and Acid 3 by IceFox · · Score: 2, Informative

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

      --
      Do you changes clothes while making the "chee-chee-cha-cha-choh" transformation sound?
    2. Re:WebKit support and Acid 3 by ardor · · Score: 2, Informative

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

      --
      This sig does not contain any SCO code.
    3. Re:WebKit support and Acid 3 by westyvw · · Score: 1

      Thats odd, using Webkit from Sid with Midori I get 100/100.

  5. Re:LGPL by stoolpigeon · · Score: 3, Informative

    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.

    --
    It's hard to believe that's how Micronians are made. Why don't we see it right now by having you both kiss one another?
  6. Re:LGPL by larry+bagina · · Score: 1
    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.

    --
    Do you even lift?

    These aren't the 'roids you're looking for.

  7. Re:LGPL by nedlohs · · Score: 4, Insightful

    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.

  8. Re:LGPL by 0racle · · Score: 2, Insightful

    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?

    --
    "I use a Mac because I'm just better than you are."
  9. Jambi (Qt for Java) discontinued by Maxwell42 · · Score: 4, Informative

    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

    1. Re:Jambi (Qt for Java) discontinued by zebslash · · Score: 2, Insightful

      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.

    2. Re:Jambi (Qt for Java) discontinued by Maxwell42 · · Score: 1

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

    3. Re:Jambi (Qt for Java) discontinued by Carewolf · · Score: 2, Interesting

      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.

    4. Re:Jambi (Qt for Java) discontinued by pembo13 · · Score: 3, Informative

      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.

      --
      "Thanks for all the money you paid to us. We've used it to buy off ISO among other things" -Microsoft
    5. Re:Jambi (Qt for Java) discontinued by Simon · · Score: 2, Informative

      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

    6. Re:Jambi (Qt for Java) discontinued by Prien715 · · Score: 1

      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?

      --
      -- Political fascism requires a Fuhrer.
    7. Re:Jambi (Qt for Java) discontinued by Simon · · Score: 1

      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

    8. Re:Jambi (Qt for Java) discontinued by ChunderDownunder · · Score: 2, Interesting

      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.

    9. Re:Jambi (Qt for Java) discontinued by theolein · · Score: 1

      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.

    10. Re:Jambi (Qt for Java) discontinued by try_anything · · Score: 1

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

  10. Awesome by sjones130 · · Score: 5, Interesting

    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!

    1. Re:Awesome by HatofPig · · Score: 4, Interesting

      You really need to keep your eye on KDevelop 4.0 then. Check out one of the main developer's blogs 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.

      --
      Silicon & Charybdis McLuhan Kildall Papert Kay
    2. Re:Awesome by sjones130 · · Score: 1

      Sweet. I'll check that out, thanks!

  11. Re:The question for users by Abreu · · Score: 3, Insightful

    You are confusing QT with KDE

    --
    No sig for the moment.
  12. GCC 3.4.5 by PhrostyMcByte · · Score: 2, Informative

    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 to the rescue!

    1. Re:GCC 3.4.5 by PhrostyMcByte · · Score: 1

      woops, using a source tree from January 2006 plus some patches. but not built then.

  13. PyQT4 - plans to change to LGPL too? by sricetx · · Score: 1

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

    1. Re:PyQT4 - plans to change to LGPL too? by wowbagger · · Score: 1

      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.

      --
      www.eFax.com are spammers
    2. Re:PyQT4 - plans to change to LGPL too? by pembo13 · · Score: 1

      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.

      --
      "Thanks for all the money you paid to us. We've used it to buy off ISO among other things" -Microsoft
    3. Re:PyQT4 - plans to change to LGPL too? by jonbryce · · Score: 1

      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.

  14. QT ftw by sapelko · · Score: 2, Informative

    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

    --
    .: sapelko dixit :.
  15. Re:Excellent! QuickTime from Apple by c_g_hills · · Score: 4, Informative

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

  16. Re:From native to web - Wt by paugq · · Score: 1

    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.

    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, too (code)

    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!

  17. Re:SQL Stored Procedures by UngodAus · · Score: 1

    Heard. Noted. Not yet (but soon).

  18. Re:Excellent! QuickTime from Apple by nawcom · · Score: 1

    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.

  19. Guess how they added 64bit support to OS X? by Ilgaz · · Score: 1, Interesting

    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.

  20. QT Creator and Python? by nurb432 · · Score: 1

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

    --
    ---- Booth was a patriot ----
  21. Re:Excellent! QuickTime from Apple by rusl · · Score: 1

    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.

    --
    Stupidity is its own reward.