Qt 5.0 released [LWN.net]

Digia, the current owner of the Qt code base, has sent out a press release announcing the Qt 5.0 release. "Key benefits of Qt 5 include: graphics quality; performance on constrained hardware; cross-platform portability; support for C++11; HTML5 support with QtWebKit 2; a vastly improved QML engine with new APIs; ease of use and compatibility with Qt 4 versions."

to post comments

Qt 5.0 released

Posted Dec 19, 2012 19:32 UTC (Wed) by Kit (guest, #55925) [Link] (8 responses)

The What's New in Qt 5 page gives a very good overview of the major changes. Looks like they've done quite a bit of refining and improvements over the last several years!

Qt 5.0 released

Posted Dec 19, 2012 19:58 UTC (Wed) by rleigh (guest, #14622) [Link] (7 responses)

The fact that you can now directly connect signal handlers without using moc to generate them is great. I vastly prefer this form from previously using libsigc++ and boost::signal; it's nice to see Qt getting the same type-safe handler style, and even nicer to see that you can use C++11 lambdas! I hated runtime exceptions when the signatures don't match, since it's entirely possible to catch this at compile time!

I assume you still need moc for SLOTs though, which if true is a shame. It would be nice to remove the need for moc entirely (or as much as is possible).

The other feature of note for me is the OpenGL work. Can anyone confirm if it's possible to build Qt to run directly on the framebuffer with a modern DRI2/KVM setup with accelereted GL? Or is X or wayland a hard requirement?

Qt 5.0 released

Posted Dec 19, 2012 20:14 UTC (Wed) by HelloWorld (guest, #56129) [Link]

> I assume you still need moc for SLOTs though, which if true is a shame. It would be nice to remove the need for moc entirely (or as much as is possible).
moc will never go away as it does more than signals and slots nowadays. Basically it adds the stuff that Objective-C has and that C++ is missing: introspection, properties and probably more.

> The other feature of note for me is the OpenGL work. Can anyone confirm if it's possible to build Qt to run directly on the framebuffer with a modern DRI2/KVM setup with accelereted GL? Or is X or wayland a hard requirement?
This kind of thing is handled by the QPA in Qt 5. You may want to look at the available QPA plugins:
http://qt.gitorious.org/qt/qtbase/trees/stable/src/plugin...

Qt 5.0 released

Posted Dec 20, 2012 9:44 UTC (Thu) by nazgulos (subscriber, #66348) [Link] (5 responses)

> I assume you still need moc for SLOTs though, which if true is a shame. It would be nice to remove the need for moc entirely (or as much as is possible).

Why moc is so bad? Do you hate others code generators, or just generated code?

Qt 5.0 released

Posted Dec 20, 2012 11:50 UTC (Thu) by rleigh (guest, #14622) [Link] (4 responses)

I'm not against generated code per-se. But in the case of signals/slots, we have had a robust, type-safe solution to replace the moc implementation as pure C++ compile-time-checked constructs which is superior to the moc-generated code. This is what libsigc++ and boost::signals both do, though they don't by default do anything with introspection--but you could add that on top. Qt5.0 gets us half way there with signal connection, and that's arguably the most important part. It would be nice if it could be taken all the way, though.

With a bit of thought, it's equally possible to do properties at compile/runtime as well, including introspection. For example, using templated property proxies and lambdas for the getters/setters. Again, completely type-safe compile-time checked etc. Example: GLib::PropertyProxy<> in GLibmm; though it's layered on top of the GObject property mechanism, it could be based on something else.

For me, the value added here is the compile-time checking, robustness, simplicity, and removal of the need for an additional code-generation step in the build. You now can't get any runtime signature mismatch failures unlike with moc. Also, when Qt is just one of many libraries being used, qmake is often not an option, particularly when Qt is just for an optional UI component in a larger project. Just like bjam isn't an option when using Boost, etc (mainly because it's incomprehensible!). And writing all the extra make rules to run moc is time-consuming and fragile when you have to do it by hand, so removing it when possible can be useful.

The other issue when integrating into a wider non-Qt project is that Qt-using code is no longer strictly C++: It's a Qt dialect which is processed into C++ at build time (I'm referring to the slots: syntax etc). And the non-standard containers can also be an issue; it would be preferable to use the C++ standard equivalents whenever possible (I know this has improved, but as someone who codes using plain Standard C++ with TR1/boost/C++11, using the standard forms by default is highly desirable). GTKmm/GLibmm manage to use standard C++ to a much greater extent, though Qt is certainly getting better, and I'm increasingly using Qt for newer projects as a result.

Regards,
Roger

Qt 5.0 released

Posted Dec 20, 2012 14:36 UTC (Thu) by krake (guest, #55996) [Link] (3 responses)

"It would be nice if it could be taken all the way, though."

I am not sure what you mean with "all the way" as the new connect() options are fully compile time based.

One of the advantages of the now additional runtime checked option is that it does not require information on the concrete types of sender or receiver, while still keeping type-safety for signal/slot arguments.

"The other issue when integrating into a wider non-Qt project is that Qt-using code is no longer strictly C++: It's a Qt dialect which is processed into C++ at build time (I'm referring to the slots: syntax etc)."

No, this is handled by the compiler itself, or rather its preprocessor. A Qt file is a standard C++ header or source file, as can easily be verified by running a C++ compiler on it manually. Same is of course true for the file generated by moc.

It would have been an unmanagable situtation for Trolltech to deliver a custom compiler for all platforms they supported.

Qt 5.0 released

Posted Dec 20, 2012 14:58 UTC (Thu) by rleigh (guest, #14622) [Link] (2 responses)

> I am not sure what you mean with "all the way" as the new connect()
> options are fully compile time based.

I'm referring to the other half of the problem, the slot definitions. Such as boost::signal<> or sigc::signal<>, both of which allow slot definition without requiring any special syntax or tool support.

> No, this is handled by the compiler itself, or rather its preprocessor. A
> Qt file is a standard C++ header or source file, as can easily be
> verified by running a C++ compiler on it manually. Same is of course true
> for the file generated by moc.

Oh, certainly. I'm not arguing with how it's implemented--in the preprocessor--, just that it does effectively make Qt-using sources a non-standard C++ dialect as a result.

> It would have been an unmanagable situtation for Trolltech to deliver a
> custom compiler for all platforms they supported.

Sure, I understand the historical reasons, and they make perfect sense in this context. But all the other signal/slot mechanisms such as sigc++ and boost::signals require nothing except compiler template support, which all compilers have supported for well over a decade now. It does seem a little odd, in 2012, not to rely on the standard library and facilities like this where it makes a lot of sense.

Regards,
Roger

Qt 5.0 released

Posted Dec 20, 2012 15:27 UTC (Thu) by krake (guest, #55996) [Link] (1 responses)

> I'm referring to the other half of the problem, the slot definitions.

You need those for the traditional variant of connect.

Are you saying that the two markup alternatives you mentioned can provide the necessary introspection data for runtime checked connect on base class pointers?

Otherwise I am a bit puzzled considering the compile time checked variants of connect seemed what you would be going for.

> just that it does effectively make Qt-using sources a non-standard C++ dialect as a result.

Hmm, I am afraid I can't follow you here either.
Given that the content is perfectly consumed by a wide range of C++ compilers, wouldn't that indicate that it is using standard C++ dialect?

Or are you saying any form of preprocessor substitution makes something non-standard C++? How does on solve includes and include guard using standard C++?

> Sure, I understand the historical reasons, and they make perfect sense in this context.

You must have put this sentence into a wrong line by accident, since it does make not sense in the context of the quoted line.

Not relying on a custom compiler for every platform does still make perfect sense in present context.

That's why Qt code has not, does not and almost certainly will not require a custom C++ compiler but will continue to work with the compilers that compiler or platform vendors release.

> But all the other signal/slot mechanisms such as sigc++ and
> boost::signals require nothing except compiler template support,
> which all compilers have supported for well over a decade now.

I wasn't aware that those libraries provide runtime connect based on introspection of base class pointers.
Maybe this could be added as a third option to Qt, leaving the traditional connect for compatibility (which is needed anyway), having one of those mechanisms you describe here taking the role of the runtime use case and the member/functor connect for the compile time use case.

Qt 5.0 released

Posted Dec 22, 2012 18:27 UTC (Sat) by rleigh (guest, #14622) [Link]

While the libsigc++ and Booost style slot equivalents don't directly support introspection (they are just class members), you could layer that on top easily enough without needing an external tool to do so; though I'm not familiar enough with the internals of moc to know if that could be done compatibly or not WRT the signature extraction. You'd probably still need some preprocessor support to register and define the slot in a single statement.

Regarding the C++ dialect issues--I think we're talking at cross-purposes here; I don't think we're in disagreement, just misunderstanding.

Regards,
Roger

Qt 5.0 released

Posted Dec 19, 2012 19:45 UTC (Wed) by Company (guest, #57006) [Link] (3 responses)

Now if only the GNOME guys would see the light and drop GTK...

Gtk and Qt

Posted Dec 19, 2012 20:25 UTC (Wed) by HelloWorld (guest, #56129) [Link]

The problem with that is that there's no migration path. This kind of thing probably needs to be done from the bottom up, so we need to unify the underlying object systems (QObject and GObject) first, then the platform abstraction layer (QPA and Gdk/Glib) etc..

This would be hard if there were only a technical issue and everybody agreed that this is the direction to go. But that's not the case, so I don't think it's ever going to happen. And just to be clear: that's a Bad Thing in my opinion.

Qt 5.0 released

Posted Dec 19, 2012 21:23 UTC (Wed) by dcg (subscriber, #9198) [Link] (1 responses)

It's easy to write that without taking a look at history and at the huge difficulties that would require such change.

Qt 5.0 released

Posted Dec 19, 2012 21:27 UTC (Wed) by halla (subscriber, #14185) [Link]

Automated ported can get quite a long way, when you consider just the code. KDAB has some tools that can do most of the porting from Motif to Qt, and I bet it wouldn't be harder for GTK to Qt.

Not that it would ever happen, of course. As you say, the past history would prevent it.

Qt 5.0 released

Posted Dec 20, 2012 0:27 UTC (Thu) by kripkenstein (guest, #43281) [Link] (6 responses)

Is Digia doing this just for fun, or is there a business plan behind it? (The old Trolltech business plan of dual-licensing has got to be impossible now with the new license.)

Qt 5.0 released

Posted Dec 20, 2012 1:19 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link] (5 responses)

The business model is licensing (some companies don't want LGPL), consulting etc. No company would do such work for fun.

Qt 5.0 released

Posted Dec 20, 2012 1:25 UTC (Thu) by kripkenstein (guest, #43281) [Link] (4 responses)

I'm surprised that's a viable business. Look at how many people use WebKit for example, and it's LGPL like Qt.

Qt 5.0 released

Posted Dec 20, 2012 4:38 UTC (Thu) by drag (guest, #31333) [Link] (3 responses)

You can see for how well for yourself:
http://www.reuters.com/finance/stocks/financialHighlights...

Qt 5.0 released

Posted Dec 20, 2012 4:47 UTC (Thu) by kripkenstein (guest, #43281) [Link] (2 responses)

? They existed before Qt, how much of their revenue is specifically from it?

Qt 5.0 released

Posted Dec 20, 2012 9:10 UTC (Thu) by jospoortvliet (guest, #33164) [Link] (1 responses)

apparently enough as the core Qt.development is going strong...

Qt 5.0 released

Posted Jan 3, 2013 20:33 UTC (Thu) by dashesy (guest, #74652) [Link]

This is great, I wish them good luck.