Qt Is Looking At Making Qt 5.6 A Long-Term Support Release

[phoronix]

Phoronix: Qt Is Looking At Making Qt 5.6 A Long-Term Support Release

Qt developers are currently figuring out plans for doing a long-term support release of their open-source toolkit as they'll soon be dropping support for a number of aging platforms...

http://www.phoronix.com/scan.php?page=news_item&px=Qt-5.6-LTS-Gauge

[lunarcloud]

This is very exciting, because the moment they can switch to C++11 is the moment they can move away from needing the moc tool. Removing extra preprocessors is a great way to drive adoption and respect from the wider C++ community.

[Azrael5]

Qt 5.5 will support Qtwebengine!?

[carewolf]

Qt already uses C++11 features. The question is if they can't be required which would simplify the code. Currently they have to be optional.

[carewolf]

Qt 5.5 will support Qtwebengine!?

It is already available in Qt 5.4.

[lunarcloud]

Qt already uses C++11 features. The question is if they can't be required which would simplify the code. Currently they have to be optional.

Right, that's what I meant by switch. Requiring the new signals-slots syntax and C++11 etc.

I was thinking about this article

[lunarcloud]

about this article

And these guys who are doing it now, but with Qt 4.8

[Karl Napf]

@lunarcloud: Qt will keep moc, at least till Qt 6. Qt promises both source and binary compatibility, and moc can not be dropped without breaking both.

Copperspice does break both, and makes defining signals way more inconvenient. I do not see Qt following that example and do not expect moc to go away before C++17 is widely available. That does allow to implement signals without requiring moc and with the same convenience that Qt currently offers.

[lunarcloud]

@lunarcloud: Qt will keep moc, at least till Qt 6[...]

Yes, I understand very well the level of professionalism in their support. I think it's possible to make moc optional, but default, until said Qt6 where it'll likely be optional but *not* default.
Just like how it'll eventually transition to QBS from QMake, but both will still work and it's about what's default and when.

[zanny]

Copperspice does break both, and makes defining signals way more inconvenient. I do not see Qt following that example and do not expect moc to go away before C++17 is widely available. That does allow to implement signals without requiring moc and with the same convenience that Qt currently offers.

They could honestly just rip off Boost's Signals2, I have used them in the past with non-Qt projects and they are pretty reasonable, especially if you do them with C++11 function objects for prettiness.

There is also a nice blog post talking about how C++11 can make signal libraries easier / faster / better. Boost is still using C++04 for its Signals2 library.