Qt 5 Alpha Released

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.

Comments

Why?

[Darinbob]

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.

Re:Why?

[Anonymous Coward]

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.

Re:Why?

[Carewolf]

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?

[harry1701]

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.

Re:Why?

[bertok]

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

Re:Why?

[msobkow]

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.

Re:Why?

[shutdown -p now]

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.

come on

[Anonymous Coward]

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

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

Re:Nokia's fate?

[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

Re:Nokia's fate?

[harry1701]

Then the KDE Free Qt Foundation kicks in: http://www.kde.org/community/whatiskde/kdefreeqtfoundation.php

Re:Nokia's fate?

[transmetal]

They've made an effort over the past year to move Qt into becoming an independent project. See http://qt-project.org/ and http://wiki.qt-project.org/The_Qt_Governance_Model . 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.

Re:Nokia's fate?

[Enderandrew]

Qt is open source. Nokia could make all future iterations closed source, and then open source version gets forked like OpenOffice and LibreOffice.

Re:Nokia's fate?

[noahwh]

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.

Re:Focus on Mobile development

[Nyeerrmm]

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.

Re:One or two Questions...

[INeededALogin]

Question is "have they changed this?"

Whats the bug number where they were notified. Why did they refuse to fix it?

AutoIt:

AutoIt has been designed to work on Microsoft Windows 2000/XP/2003, Microsoft Windows Vista, Microsoft Windows Server 2008/2008 R2, Microsoft Windows 7.

So you are complaining about an open-source development toolkit that supports every major OS and several Mobile OSs against a Windows-Only, proprietary application. I really don't think you are going to find many sympathizers here.

Re:Nokia's fate?

[fast turtle]

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.

Re:Nokia's fate?

[Daniel Phillips]

Correct. I believe the QT foundation has a longstanding agreement in place to ensure that.

Re:If they plan on going mobile then i'm afraid

[tibit]

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.