Qt 4.8 Forked Into New "CopperSpice" C++11 GUI Library

[anda_skoa]

I haven't seen a single change in Qt 5 that is relevant to me

I would say, aside from the internal improvements, the main change developers of standard widget based applications are likely to see in Qt is the way better platform integration.

The QPA system has many extenion points which make applications fit into their environment additional to the native styling (which is the most obvious one).

Cheers,
_

[cs-barbara]

So you're "updating features and fixing bugs", why didn't you contribute directly to Qt5 ? Starting with Qt 5.6 a lot of C++11 will be allowed.

We started working on CopperSpice in May 2012, long before Qt 5 was released. Our approach was to remove moc and fix existing issues, which we have done. Our goal now is to move our project forward and redesign and enhance areas like the contain classes, atomics, etc. We have been using C++11 from the beginning. In our opinion Qt 5.6 will still not move in the direction we believe a current day GUI library should go.

[cs-barbara]

As for the actual topic, I think it sounds like a nice initiative.
I am all for better C++11 support and removing dependencies on MOC for advanced Qt programs which requires introspection.
That said, I would've preferred to see it as patches for Qt.

There is no way the Qt Project was going to allow us to submit any code to remove moc as they do not believe it is a problem which can be solved today. They also are not willing at this time to require C++11. So sadly, it was not possible to submit any of our work.

[cs-barbara]

I've just compiled that example, and yes, the Qt program was compiled without MOC.

Qt 4 and Qt 5 both use moc internally, so the baggage of moc is still there even if you can not see it. The intense bootstrap process to build QtCore and moc makes working on QtCore awkward and error prone. If you are not using moc you are very limited in what portions of Qt you can actually use.

[anda_skoa]

They also are not willing at this time to require C++11. So sadly, it was not possible to submit any of our work.

My understanding is that it is not a matter of unwillingness but a problem of compiler support, e.g. VS2008. So mostly a transitional thing, there will be a point when that version of VisualStudio no longer needs to be supported.

Given that long term core contributors have been regularily researching replacing moc, I doubt that a contribution of such a replacement would not be welcome.

Cheers,
_

[GdeR]

Qt without MOC: Good. More C++11 support: Good. Version 4.8.7: ... Deal Breaker. I'm not going to give up on Qt5. Who is? The intention is great, but the project either came too late or it addressed the wrong Qt version. Qt5 has been around for 5 years now.. and Qt6 is on radar..