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

[cs-barbara]

I have programmed a moderate project using Qt5 and it also does not use MOC. .

Qt 5 use moc, it has not been removed in their product. But even if you are not using QObject, or Signals/Slots, Qt uses moc internally. If you do not use moc there are large portions of the Qt meta object API which will not work with your classes.

[cs-barbara]

Removing moc implies trimming reflection support from Qt, which is a major step back unless c++ has compile-time reflection support.

We did remove moc in CopperSpice, but we did not remove any reflection. Everything you have in Qt for signals, slots, properties, connections , etc will work in CopperSpice.

[bison]

> the libraries can be linked into any standard C++ application

If this means what I think it means then I'm very interested. My main objection to Qt is that one doesn't just use it as a library; you have to write a Qt app that takes over the build process. I would very much favor a less invasive toolkit.

[cs-barbara]

> the libraries can be linked into any standard C++ application

If this means what I think it means then I'm very interested. My main objection to Qt is that one doesn't just use it as a library; you have to write a Qt app that takes over the build process. I would very much favor a less invasive toolkit.

This does mean exactly what you think it does. We wanted CopperSpice to be true C++ GUI library. Please take a look at our overview documentation for more information about CS.

http://www.copperspice.com/docs/cs_overview/index.html

We moved off of SourceForge last month and have set up a forum and download pages. We have source and binaries on line. Due to all the activity we are pushing the git repo to GitHub shortly. Feel free to email us directly at [email protected]

[giucam]

>the libraries can be linked into any standard C++ application

If this means what I think it means then I'm very interested. My main objection to Qt is that one doesn't just use it as a library; you have to write a Qt app that takes over the build process. I would very much favor a less invasive toolkit.

What does this mean? You don't need to "write a Qt app that takes over the build process", whatever that means. Qt is a normal C++ library.

[lowflyer]

We developed CopperSpice for many reasons, one of theme was to remove moc. There were many other limiting issues we found with Qt and strongly believe CopperSpice offers a better approach as a C++ GUI library. One of our goals is to change the contain classes Qt used to leverage the STL.

Barbara, congratulations to you and the whole CopperSpice team! This is a development that has been long overdue. I have been working with Qt5 for the last 5 years and with C++ for the last 10 years. I like working with Qt a lot, but the Qt libraries always just felt "out of place" compared to the rest of C++. To change the Qt containers towards STL is a very important goal. With C++11 becoming common place and C++17 on the horizon this will just become more important.
I want give you and your team a heads up, you are on the correct path.

[carewolf]

We did remove moc in CopperSpice, but we did not remove any reflection. Everything you have in Qt for signals, slots, properties, connections , etc will work in CopperSpice.

I doubt it is everything, but some 90% of it is possible. See http://woboq.com/blog/reflection-in-cpp-and-qt-moc.html

[Luke_Wolf]

well, good luck, but I don't see a market for this. Everyone who cares about Qt is basically on Qt5 now, and my impression was that people who made the complaints that you're targeting (moc... stl...) had no intention of using Qt anyway, and were reaching for something to bash on it for.

[curaga]

Well well, this addresses most of my complaints about Qt: moc, NIH containers, and needless bloat that has no place in a toolkit (3d engine, seriously). The JS-ified direction of Qt5 put me off Qt5. I can see myself using CS in the future. I hope you'll also address Qt's very long build times, and keep removing needless parts.

[Ancurio]

> the libraries can be linked into any standard C++ application

If this means what I think it means then I'm very interested. My main objection to Qt is that one doesn't just use it as a library; you have to write a Qt app that takes over the build process. I would very much favor a less invasive toolkit.

You can use Qt in a cmake based project just fine. Not even complicated.

Well well, this addresses most of my complaints about Qt: moc, NIH containers, and needless bloat that has no place in a toolkit (3d engine, seriously). The JS-ified direction of Qt5 put me off Qt5. I can see myself using CS in the future. I hope you'll also address Qt's very long build times, and keep removing needless parts.

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.