Forgot your password?
typodupeerror
GUI Open Source Programming Software

Qt 5 Alpha Released 117

Posted by Unknown Lamer
from the trolls-with-advanced-technology dept.
After nine months of effort, Nokia's Qt Lab has announced the availability of the alpha release of Qt 5. Goals achieved for this release include a new platform abstraction layer, a re-architected graphics stack, and the inclusion of Qt Quick as a first-class citizen (hitting version 2.0, and using Google's V8 Javascript engine to boot). Quoting Lars Knoll: "'Qt 5 should be the foundation for a new way of developing applications. While offering all of the power of native Qt using C++, the focus should shift to a model, where C++ is mainly used to implement modular backend functionality for Qt Quick.' I can say that we came a good way closer to this vision with Qt 5.0. The model is working nicely on the embedded side of Qt where UIs are full screen. On the desktop, we have laid most of the foundations required for this model, but it’ll take us until 5.1 or 5.2 to really take this into use." Nokia has posted the the source and detailed release notes on the Qt wiki.
This discussion has been archived. No new comments can be posted.

Qt 5 Alpha Released

Comments Filter:
  • by rrohbeck (944847) on Tuesday April 03, 2012 @02:41PM (#39564073)

    What's going to happen with Qt if/when Nokia goes down the drain and gets swallowed by (probably) Microsoft?

    • by Anonymous Coward

      Notice it is Qt Labs releasing Qt and not Nokia?

    • by Anonymous Coward

      Qt would remain open source, and ripe pickings for someone willing to use it.

      Nokia has already delivered massive value and r&d effort on Qt5; it wouldn't go silently into the night, regardless of what happens with Nokia.

      That's part of the beauty of open source: technology is not anchored to a publicly traded company, a competitor can quickly poach a developer team if it sees a need for one.

    • Re: (Score:3, Informative)

      by Anonymous Coward

      In the event Qt Labs/Nokia don't maintain the Qt framework anymore the code gets passed over to the KDE developers. I believe the code would then be either under the BSD license of a dual BSD/GPL license. You can find the details here: http://www.kde.org/community/whatiskde/kdefreeqtfoundation.php

      • QT is already licensed under LGPL and GPL v3 which answers the question of who has the right to continue developing and distributing QT libraries. The answer is: you, me and everybody.

        Furthemore, there is an agreement in place the ensure that QT continues to be licensed under LGPL. Here it is. [kde.org] Additionally, there is an open governance [kde.org] framework in place to guide ongoing development, which frankly places the QT project head and shoulders above Android in terms of community engagement, open development and go

    • Re:Nokia's fate? (Score:5, Informative)

      by harry1701 (1553093) on Tuesday April 03, 2012 @02:56PM (#39564245)
      Then the KDE Free Qt Foundation kicks in: http://www.kde.org/community/whatiskde/kdefreeqtfoundation.php [kde.org]
      • by Kjella (173770)

        I wouldn't put too much faith in that agreement if it came down to hostilities, as long as there's one "important" release each year which Nokia claims is good enough and the qt foundation isn't and then put a lawyer on it to drag it out it'll be tied up for years. Also it explicitly says "For the avoidance of doubt, the aforementioned definition does not cover the Qt toolkit for other platforms (e.g. MS Windows, Macintosh, Symbian)" so they can strip out many platform-specific files. Most likely there'll j

    • Re:Nokia's fate? (Score:5, Informative)

      by transmetal (904896) on Tuesday April 03, 2012 @03:07PM (#39564375)
      They've made an effort over the past year to move Qt into becoming an independent project. See http://qt-project.org/ [qt-project.org] and http://wiki.qt-project.org/The_Qt_Governance_Model [qt-project.org] . In some respects, Nokia's already put all their eggs in Microsoft's basket (their abandoning of Meego and non Windows Phone mobile OSs), and it doesn't seem to have impacted Qt's development in any noticeable fashion.
      • by Anonymous Coward

        Well it seems they plan to release some low cost linux based phones for 100€ or so? Dunno probably burning platforms is just a hobby of them. But i really hope that qt is getting stronger out of this.

    • Re:Nokia's fate? (Score:5, Informative)

      by noahwh (1545231) on Tuesday April 03, 2012 @03:20PM (#39564547)

      They've been moving resources around for a while now to ensure that QT isn't tied to Nokia's success.

      Commercial support contracts have been sold to Digia. They've been the drivers behind several patch level releases already, including 4.8.1 a couple days ago.
      The QT project has adopted an open governance model, with members outside of Nokia. They've moved their web presence off of Nokia's servers. They switched to LGPL licensing from QPL over a year ago.

      If Nokia diverts resources progress may slow, but QT is not going anywhere. It will almost certainly outlast Nokia.

    • Isn't Qt under an open governance now?

      http://wiki.qt-project.org/The_Qt_Governance_Model
      http://qt-project.org/
    • Re:Nokia's fate? (Score:4, Informative)

      by fast turtle (1118037) on Tuesday April 03, 2012 @06:35PM (#39566899) Journal

      Why not read the QT Promise?

      QT is under a dual development and the source code is held in escrow by the FOSS foundation to be released under GPL should QT Labs go under.

  • by Anonymous Coward

    Looks like more and more focus on mobile development (Qt Quick, Javascript as your UI) and less and less targeting for desktop systems. Which is too bad, and if they are *publicly* announcing that it won't be until 5.2 that the desktop becomes usable again, it looks like it's time to either fork the 4.8 version or start over with some other product.

    • by Nyeerrmm (940927) on Tuesday April 03, 2012 @03:34PM (#39564755)

      My interpretation is that Qt Quick is not yet suitable for desktop use, while the 'old-style' C++ objects should remain as usable as they are now.

      While I'd love to see how Quick could help with improving my workflow, since I only work on desktop interfaces I guess I'll have to wait.

    • Why Qt Quick is "focusing on mobile"? From what I've read about it, it looks like a (long overdue) open source alternative to WPF to me - it espouses largely the same principles with separation of UI markup and code and a convenient syntax to bind two together, with the only difference being that it's backed by C++ rather than .NET (and it's much faster).

  • Why? (Score:4, Insightful)

    by Darinbob (1142669) on Tuesday April 03, 2012 @02:50PM (#39564193)

    Why is everyone heading to this "everything is a web app" model? A scripting languages embedded into an app is find but it should be used for quick mods and customization instead of core functionality, and should be layered on top of the application and not the base that the application is built from.

    • by Anonymous Coward

      Because they are struggling for relevance in the mobile market. They somehow think that foisting Javascript into apps is that path whilst alienating their desktop developers. The problem is that none of the truly relevant mobile OSes these days have an official Qt port. Maybe in a couple of years they understand their folly and return to their c++ roots rather than this bastardized Javascript junk.

      • Re:Why? (Score:5, Insightful)

        by Anonymous Coward on Tuesday April 03, 2012 @03:03PM (#39564325)

        You don't have a clue what you're talking about. QML greatly simplifies 90% of the UI development while making it significantly easier to target multiple devices with the same UI, regardless of screen size or aspect ratio. A desktop-focused, c++-based UI model is hardly the better way to do it.

        • by AdamJS (2466928)

          When your core users are using your software SPECIFICALLY for desktop C++ development, bastardizing the software in some schizophrenic, hopeless pursuit of an area few of them want is quite the wrong way to do it.

          • It's odd that Nokia is *still* pushing this QML stuff, although it did make sense (to Nokia at least, if not to most Qt developers) while they has been pursuing a Qt-based smartphone strategy.

            • It makes interface designer tools easier to create. That said, I will stick with the on-the-metal c++ QT interface, it's easy enough to work with. The designer is nice for quick mockups.

        • Can anyone point to a good example of a Qt Quick/Declarative/QML (What exactly is the correct terminology?) application for the desktop environment. As a Qt dev with traditional Qt widget desktop apps I'd like to see a good example, preferably open source, of a non-trivial desktop application using the mobile-oriented Qt Quick/QML/Declarative. I suspect I'll be waiting a while.

    • Re:Why? (Score:5, Informative)

      by Carewolf (581105) on Tuesday April 03, 2012 @03:10PM (#39564411) Homepage

      QML2 is pretty cool. I had the same attitude to QML1, but QML2 is a pretty good language to program the GUI in, while doing still all the real work in C++. Essentially QML is to Qt Designer what LaTex is to Word.

      • Re:Why? (Score:4, Insightful)

        by msobkow (48369) on Tuesday April 03, 2012 @06:13PM (#39566713) Homepage Journal

        Of course if you've never worked with a document description language like Tex, you probably won't grasp the significance of that statement.

        I like the C++ object model Qt uses. It reminds me of the "Elements" environment from the company formerly known as Neuron Data. I was surprised to hear they're still around, and there are still production applications written with it that need maintenance and updates because they're not ready to be retired yet.

        But Qt is brought up to date with modern C++ features like template programming; I don't know if Elements has been similarly reworked. GTK is a pretty nice layer as well, but it's a portable graphics layer rather than a graphics abstraction like Qt or Elements. You can write custom widgets in Qt or Elements and have them work on multiple platforms, sort of like Java/Swing for C++. I'm not so sure about how to do so with GTK.

        It was refreshing to see them being honest that it's not really going to be ready for production use until 5.2 or thereabouts.

        • It was refreshing to see them being honest that it's not really going to be ready for production use until 5.2 or thereabouts.

          Indeed. It's important to note that QT 4.x is already nice to work with, stable and mature. I would like to see QT foundation really take their time getting 5 right, there is no good reason to push it out in a hurry.

    • by SQLGuru (980662)

      Because it's the closest thing to a true write-once / run-anywhere model that's working. A web app will run on the desktop, tablets, e-readers, consoles (Wii has Opera), phones (even many of the average-intelligence phones). Mac, Linux, PC. Sure, there are some browser issues, but those can generally be overcome by switching browsers when that is an option. I still think we need native apps, but not everything needs direct access to hardware or complex calculations that would call for it.

      The biggest pro

      • the problem is that you can't magically make a web app look metro-y on windows 8 and ios-y on ios using THE SAME CODE BASE.

        by the time you do the relevant coding to polish it up well enough you might as well do a native app.

        write-once, run-anywhere is the biggest load of bullshit to ever appear in computing.
        it's a sham, it's a joke, it's a lie, it's a hoax, it's a scam, and anyone who pushes for it should be ashamed of themselves for basically *LYING* to whoever's paying them.

        • by aliquis (678370)

          That's not necessarily a problem imho.

          You can make nice non-standardized UIs to (I prefer a button working as a button, a scrollbar to work as a good scrollbar (Fuck you Facebook (yeah and an 'x' to work like close and edit to 'work' like edit ...) and menus to be on the top but I'm fine with for instance the look of Lightroom, Photoshop, that new Office .. what are they calling it? Gaming interfaces, ...)

        • by jbolden (176878)

          write-once, run-anywhere is the biggest load of bullshit to ever appear in computing

          write-once, run anywhere obviously does work the website you are on is a good example of that. Windows, OSX, and Linux users all experience roughly the same thing. The issue is that this application is of fairly limited complexity. As application complexity increases platform specific features become desirable. However, the vast majority, possibly overwhelming majority of applications are simple.

    • Re:Why? (Score:4, Interesting)

      by harry1701 (1553093) on Tuesday April 03, 2012 @03:13PM (#39564455)

      Why is everyone heading to this "everything is a web app" model?

      Qt isn't going for web apps. It's going for Qt Declarative / Qt Quick. Just write some GUI apps with classic Qt and with Qt Quick, then you'll quickly realize how much more powerful it is to write GUIs declaratively instead of imperatively.

      • So what is the case for declarative GUI programming?

        I'm a big fan of pure functional languages, but it's not obvious to me why declarative languages are especially suited to GUI's.

        • Re:Why? (Score:5, Informative)

          by bertok (226922) on Tuesday April 03, 2012 @05:32PM (#39566279)

          That's a perfectly valid question, and the answer is not obvious at first.

          When you come from a programming background, you have a very powerful hammer, and everything ends up looking like a nail, including GUIs. The problem with this approach is that you can never have either a non-programmer or a GUI tool help design your user interface. For trivial applications this isn't a problem, but it quickly becomes limiting on larger projects.

          Microsoft had an interesting hack to make GUI design work with imperative languages -- split class files. One file would contain only a strict subset of the imperative language that the GUI designer could handle, the other matching file would contain the real code. This solution was fragile and would often result in the designer failing to open. This was already half way there to a declerative domain specific language, because the subset of the imperative language that the designer coud parse forbade any control flow. I first had the "lightbulb" moment when I saw Microsoft's next-gen XAML designers, where they basically formalized the GUI language into an explicitly declerative document format with a strict grammar. It allowed more complex GUI designs with well defined parsers, object models, design-time appearance, etc... All the problems just vanished.

          This is by no means a Microsoft invention, declerative visual languages have always been more successful, flexible, and interoperable. A case in point is HTML, which is a purely declerative language, which has lots of advantages that has contributed to its success. Try putting yourself into the shoes of a search engine developer and imagine if instead of declerative SGML-derived pages, you had index imperative PostScript? Not just any old automatically generated PostScript intended for printing, but developer authored PostScript with as much complexity as a typical JavaScript library! How would you go about writing a designer for a language like that? You'd start by restricting the problem to some strict subset...

          • The problem with this approach is that you can never have either a non-programmer or a GUI tool help design your user interface.

            So then Qt Designer and Interface Builder, two tools for GUI design, don't exist?

            • by bertok (226922)

              Less than a minute of Googling later: Qt Designer's UI File Format [qt-project.org]

              Your counter-example to my point uses an XML-based declarative UI file format with a strict validating schema.

              I'm not sure what you mean by Interface Builder you mean the Apple tool, which uses .NIB or XIB files. Those formats are -- if anything -- closer to XAML than even the QT format, as they contain XML representations of the GUI document object model.

              As far as I can see, neither format supports imperative concepts such as loops or other

              • As far as I can see, neither format supports imperative concepts such as loops or other control flow.

                Right, loops and other control flow belong in slots (program action code in case anyone doesn't know) not in the interface definition.

          • QML will seem like Chinese to anyone without some programming experience, so, if they are going to produce anything interesting, they will do it with UI designer applications, not by programming directly in QML.

            Poor unsuspecting C++ programmers will then be given the QML code produced by the UI designer tool and try to dhoehorn it to the C++ application. They will feel tortured, because the QML fed to them will be not that readable (most automated code production tools produce awful code), the UI designers

        • Re:Why? (Score:4, Insightful)

          by shutdown -p now (807394) on Tuesday April 03, 2012 @06:50PM (#39567025) Journal

          So what is the case for declarative GUI programming?

          Describing UI in markup is plainly more convenient than writing verbose code to construct widget trees. And declarative property bindings are much more concise than the usual OO way to plumb together model and views.

          Basically, it lets you focus on writing code where it's the best way to solve a problem - in your model - and use a more convenient DSL (in the case of Qt Quick, QML for markup and JS for bindings) for view-related stuff and plumbing between the two.

      • by Lussarn (105276)

        Qt isn't going for web apps.

        http://qt-project.org/wiki/Qt_for_Google_Native_Client [qt-project.org]

    • by Lussarn (105276)

      Everything will eventually be web/net apps, you can quote me on this 10 years from now...

    • by Korin43 (881732)

      Why is everyone heading to this "everything is a web app" model? A scripting languages embedded into an app is find but it should be used for quick mods and customization instead of core functionality, and should be layered on top of the application and not the base that the application is built from.

      Because some people are more concerned about actually making things than meeting your standards of application development.

    • by steelfood (895457)

      Computers are getting more and more powerful, with more and more computation and storage resources readily available. So the performance hit of an interpreted language running on top of a native language is not as big of a deal nowadays.

      It's far easier for many people to code in something they're familiar with (JS, web technology), instead of in something completely new (QT's API). Thus, to drive adoption rates, as well as to make life easy for many people, they put web technology on top of the API and let

      • by Darinbob (1142669)

        Not all computers are bigger and more powerful. Some computers are still relatively tiny, some need to pull back on the horsepower to save cost, power, battery life, etc. There is more to computing than desktops. Can people let their smart phones run all week without charging? Probably not and part of this reason is that no one bothers much with efficiency anymore.

        Now for programming familiarity you're right. However the vast majority of Qt programmers are probably far more familiar with C/C++ than wit

  • come on (Score:5, Funny)

    by Anonymous Coward on Tuesday April 03, 2012 @02:50PM (#39564199)

    How can you start that sentence but not finish it thusly:

    "After nine months of effort, Nokia's Qt Lab has given birth to..."

    • by Anonymous Coward
      That's labored...
  • that they have probably waited too late. Nokia is irrelevant now as far as QT is concerned and so what is MS buys them as some point out? MS is pretty much irrelevant as well. We have to remember that the mobile market is in its infancy and Apple and Google are the only ones poised for growth in this market. Just imagine what its going to be like in 3 or 4 years?

    QT was nice - but I would like to know what would prompt anyone, any business or anyone else to be compelled to work with QT when you have the
    • by AdamJS (2466928)

      On the desktop, it is an extremely fluid, extensible, quick yet powerful way of developing visual applications in a language that many love (C++).
      I would quite like it if I could build applications for the core mobile devices under that exact same setup.

      But that isn't what they are aiming for, and you're right, their sights seem set on irrelevancy and failure.

    • by tibit (1762298)

      So, what exactly would you use to target Windows, OS X, common Unices, and some embedded devices, all from one codebase?

      • wxWidgets? GTK+? FLTK? I could go on.

        • by tibit (1762298)

          They have nowhere near the functionality of Qt. Never mind the handwritten introspections in GTK. You'd think people could use, you know, computers to do the mundane for them. The distaste for using tools other than the holy compiler is awful. You've got all those beautiful resources, yet you choose to be confined to the expressiveness (rather, lack thereof) of C. Yay.

          • by 21mhz (443080)

            Never mind the handwritten introspections in GTK. You'd think people could use, you know, computers to do the mundane for them. The distaste for using tools other than the holy compiler is awful. You've got all those beautiful resources, yet you choose to be confined to the expressiveness (rather, lack thereof) of C. Yay.

            Ever heard of GObject introspection and Vala?

            • by tibit (1762298)

              With plain GObject, you had to handwrite all that crap! In Qt, you write a method signature once, you declare it as a signal or a slot, and you're done. IIRC with GObject you have to tell the framework about everything: the name of the method, what arguments it takes, all that other crap, it's insane that anyone would still be expecting application developers to handle this crap by hand. Of course Vala changes all that, and it provides more functionality than Qt's moc, I give them that. But it's a work in p

              • by 21mhz (443080)

                With plain GObject, you had to handwrite all that crap! In Qt, you write a method signature once, you declare it as a signal or a slot, and you're done. IIRC with GObject you have to tell the framework about everything: the name of the method, what arguments it takes, all that other crap, it's insane that anyone would still be expecting application developers to handle this crap by hand.

                Of course not, the GObject introspection compiler can extract basic types from the source. It needs extra annotations for semantics that cannot be reflected in plain C.

                Of course Vala changes all that, and it provides more functionality than Qt's moc, I give them that. But it's a work in progress, so it's not really on equal footing to Qt.

                It's quite stable and is used for things such as Folks, the GNOME contact information storage.

                • by tibit (1762298) on Wednesday April 04, 2012 @10:53PM (#39581353)

                  GObject introspection tool seems to be a recent thing -- that's what I glean from what passes for their documentation. Never mind that the tool itself is not documented within GObject documentation, so don't blame someone who refers to official documentation (not the live crapfest) for not finding it. Various anti-Qt-fanbois have been whining for the longest time about the fact that Qt uses an extra tool (like if that was hard, gimme a break). It was GTK's supposed win factor that you could do everything manually; of course if you feel so inclined you can code up QObject metadata by hand too, what moc does isn't magic.

                  Suddenly --- boom, GTK has not one but two brand-new tools that generate C code: the introspection compiler, akin to moc, and Vala, a whole new language. I'd hardly call the GObject introspection project innovative in any way, I mean come on, moc has been with us for 15 years or so. Yes, they finally realized that not everyone is a masochist even if they write in C, so good for them, but IMHO it's a bit too little, too late. Oh, and good luck finding it if you don't know it's already there.

                  As a professional developer, I would not really bother even looking at their stuff, the documentation is so bad. From my viewpoint, the fact that the Gnome project is cut up into so many libraries doesn't help at all, nor does it instill any confidence. The individual libraries are all a crapshoot from integration viewpoint: some use GObject, some don't, the API conventions differ, it seems like a loosely bound mess. When you work with a monolithic framework like Qt, at least you can count on some measure of self-consistency.

      • by DCFusor (1763438)
        Perl, Glade. Already do.
        • by tibit (1762298)

          Glade is a RAD tool to enable quick & easy development of user interfaces for the GTK+ toolkit and the GNOME desktop environment.

          So, Glade is akin to Qt Designer. So Glade is not a framework, GTK is.

    • Waited too late? My Sharp Zaurus SL-5600 shipped from the factory running Qt a decade ago. That's five years before the iPhone was released. Qt is not a newcomer. It is one of the most ancient toolkits in this market.

      • by gl4ss (559668)

        Waited too late? My Sharp Zaurus SL-5600 shipped from the factory running Qt a decade ago. That's five years before the iPhone was released. Qt is not a newcomer. It is one of the most ancient toolkits in this market.

        that's exactly the thing that makes nokias qt effort look like they wasted a lot of money to the tune of 100millions+ with this endeavor. you see, their qt for mobile took a horrible amount of time until it wasn't so badly broken that you could write actual apps with it(it's "ok" now, but wasn't when they were making the big push to companies about it being the future model for all nokia development).

        (too much money == too many people is probably the reason too why it got delayed and delayed and shipped bro

    • by Formalin (1945560)

      We have to remember that the mobile market is in its infancy and Apple and Google are the only ones poised for growth in this market. Just imagine what its going to be like in 3 or 4 years?

      That's a goofy statement. 4 years ago Nokia and RIM were on top of the world, what makes you think that Google and Apple won't see the same fate?

      I think it is far from infancy... closer to saturation.

    • Nokia is irrelevant now as far as QT is concerned

      Not entirely. Please correct me if I'm wrong, but Nokia still has fulltime QT devs on staff. And it looks like QT has pretty much landed on the N900 [nokia.com], about the only Nokia product that actually has legs in spite of Elop's efforts to kill it.

    • by jbolden (176878)

      QT has binding to widget sets from many languages as does GDK. If you want to use a non standard language, particularly one where you want non standard primitives (i.e. you want thing other than integer, string... to be first class objects) QT makes it easy. Interesting enough one of the obvious areas that this sort of application makes sense is programming language GUIs. For example the dynamic language GUI problem hasn't been solved since "evaluatable statements" is a complex context specific idea whil

  • I just took a look at QML on Wikipedia and the code examples aren't exactly awesome. I wish they would have stuck closer to JSON syntax.
    • QML is as close to JSON as it can be while still supporting all the features that are needed for the concept to work. I'm not sure in what way you would like for it to be closer to JSON? I suppose the most major difference is that where JSON is weak typed QML is stronger typed. Properties are pretty strong typed, whereas the included JavaScript in signal handlers and other places is (obviously) completely weak-typed. But even the stronger-typed properties are not as strongly typed as they would be in C++.

      Fo

  • by dan325 (1221648)
    I hope that doesn't mean that QT 5 is x86/amd64-dependent because V8 is. I would hate for QT to be locked into one architecture.

Every nonzero finite dimensional inner product space has an orthonormal basis. It makes sense, when you don't think about it.

Working...