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

[cs-barbara]

Qt containers and strings all have COW built-in, something the STL lacks. Also, Qt started development a long time ago, when the STL was still very fresh and you couldn't rely on it on all platforms. We just got hashes and sets for hells sake.

Our plan with CopperSpice is to leverage the STL and remove the duplication that still exists. Most of the containers should inherit from the STL. Time to leverage C++11 in GUI programming.

[lethal]

Our target is for anyone using C++ who wants a GUI library. Not everyone using Qt 5 is happy with that project. There are a lot of developers who would like to see the existing features updated and bugs fixed. CopperSpice is doing just that.

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.

[GreatEmerald]

If this had backwards-compatible API, then it would be a nice idea: it would eventually be able to replace Qt4 for old apps not migrated to Qt5. But as a yet another toolkit, meh, I don't think it has much perspective. At least if it was based on Qt5 it would have a shot, but as it is...

[bison]

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.

The Qt project may not be that interested in bug fixes; see https://www.youtube.com/watch?v=2l7ixRE3OCw starting at ~14:00

[duby229]

Our plan with CopperSpice is to leverage the STL and remove the duplication that still exists. Most of the containers should inherit from the STL. Time to leverage C++11 in GUI programming.

Consider me blind, deaf, and dumb when it comes to programming. But, for what it's worth I always consider simpler better. If what happens is simpler code exposing the same capability, then I'm all for it. From a non-programmers perspective that's what CopperSpice sounds like.

[Luke_Wolf]

Consider me blind, deaf, and dumb when it comes to programming. But, for what it's worth I always consider simpler better. If what happens is simpler code exposing the same capability, then I'm all for it. From a non-programmers perspective that's what CopperSpice sounds like.

well... removing the moc by using C++11 features does make things simpler (hence no longer needing a code generator), but replacing Qt's containers with STL ones on the other hand doesn't. It's just replacing one set of well tested stable containers for another where the Qt ones were a bit more advanced in their working. They do get to drop a fair bit of code from the repo but given their stable nature that's not that big of a benefit.

[sandy.martel]

Qt is not a pure C++ library. If it was you could link with a Qt library and the moc code generation step would not be required. Building a Qt application requires a build system which is keenly aware of moc.

<sarcasm>
Totally right! The moc is a tool that conveniently generate C++ source code for the user but it is well know that code automatically generated cannot be considered standard. The standard mandate that every single line of C++ code MUST be written by a human being. If you're a real C++ programmer, you write your own code, even the tediously repetitive, error prone code that could easily be automated. If you don't, then your project forgo the right to be called "pure C++". Note that you can use auto complete in your code editor (so effectively let the editor write code for you), but please, don't tell anyone! The "pure C++" police might get you and revoke your C++ license.
Bottom line, write all your source code yourself and remember that only 'make' is approved as a tool for "pure C++" (again, as long as you write your Makefile yourself!, using cmake or qmake will get you nowhere).
</sarcasm>

[Znurre]

#include <QApplication>
#include <QPushButton>
#include <QMessageBox>

int main(int argc, char **argv)
{
    QApplication application(argc, argv);
    
    QPushButton button("Click me");
    button.connect(&button, &QPushButton::clicked, [&] { QMessageBox::information(&button, "Title", "Hello world!"); });
    button.show();
    
    return application.exec();
}

 [FONT=monospace][COLOR=#000000]g++ ./main.cpp -lQt5Core -lQt5Gui -lQt5Widgets -fPIC -I/usr/include/qt/QtWidgets/ [/COLOR]
-I/usr/include/qt -std=c++11[/FONT]

Yeah, Qt is not a normal C++ lib and you can't compile Qt programs without MOC. </sarcasm>
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.

Also, automake seems like a huge step backwards to me.

[Nth_man]

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

[doom_Oo7]

Starting with Qt 5.6 a lot of C++11 will be allowed.

What does this mean ? You can already compile Qt apps fine with -std=c++14 and use all the C++ features that you'd like. Of course the Qt API don't make use of everything new under the sun (like rvalue ctors for containers, etc.) but this is an API problem, not a language problem.