
CopperSpice, a Modern C++ Fork of Qt - ingve
http://www.copperspice.com/
======
cjslep
Qt's Contributor Summit just ended, and one of the topics was C++11 support
[0]. The key takeaway is Qt 5.6 will start the move away from C++98 towards
C++11 support, though not fully C++11 mainly due to the MSVC compiler's
limitations. The joy of being cross-platform.

That being said, I don't immediately see the value of using CS over Qt. Binary
size alone is not generally worth jumping ship from an established community.
I'm also not sure why you would replace moc with template magic - moc will
generally not fail (or will tell you if, say, you forgot to inherit from
QObject), whereas template errors are midæval latin on a good day. The source
files generated by moc have a lower bar to read through its generated code
(making the Qt framework more accessible and seem less like magic), whereas
templates require a very good understanding of metaprogramming (which is a
less common skill).

Also the 4.8 pick was an odd choice. Many significant changes that happened to
5.0 were made from a maintenance standpoint. Or "lowering technical debt" if
you are playing buzzword bingo. Of all the issues, this is the biggest one in
my opinion.

[0]
[http://wiki.qt.io/QtCS2015_ModernCpp](http://wiki.qt.io/QtCS2015_ModernCpp)

~~~
frozenport
One thing broken with moc is parralel build in MSVC. I think we all agree that
moc is a dirty hack and needs to go.

~~~
slavik81
I'd blame vcbuild/msbuild for its oddly limited parallel build rules. If you
feel like switching build tools, I've personally used cmake, bjam, waf and
qmake /w makefiles. All parallelize on both Windows and Linux. I'd recommend
cmake or qmake /w makefiles, though qbs is worth looking into.

We certainly don't all agree that the moc should go. An extra compiler adds
complexity to the build, but the build is fast and the generated code is
simple. That said, I'm interested to look into CS's alternative.

------
seletz
Hmm. On a (quick) glance, I can't find:

\- a license

\- a repository -- I very much like to browse the code, issues, PRs ...

\- some tutorials -- I often judge projects by whether or not their tutorials
work OOTB

Unfortunately, that's how _I_ evaluate tools. It's a big red flag for me if
one of these things is missing in new projects -- especially when it's a fork
(is it?) of something else.

Maybe the author(s) can add these?

~~~
jryan49
Seems to be all here:
[http://www.copperspice.com/docs/cs_overview/index.html](http://www.copperspice.com/docs/cs_overview/index.html)

~~~
seletz
Duh, OK. My bad.

------
eklavya
<sarcasm> Oh my god. And he/she is forcing me to use this, that too for free?
Whatever will I do? Such a waste of his/her time, I demand compensation.
</sarcasm>

Why so much negativity people? It's a huge undertaking and an awesome
accomplishment. Why shouldn't he/she do it? Remember, we are (most of us?) in
it for the love of it.

~~~
scrollaway
It's an obscure fork of a massive project, on an outdated version, with no
chance of further support, no VCS, no discussions, no background and no author
here to back any of it up.

The negativity really shouldn't be a surprise.

~~~
dman
To be perfectly honest a fork in Qt does not surprise me. Most of the people I
know who are using Qt use the QWidgets api which has been neglected since 4.8
. Increasingly Qt development appears to be geared for completely new
paradigms (Mobile, Scene graphs, Styling via CSS, QML, QtQuick ...) while
leaving the core desktop functionality at a stand still.

~~~
nhaehnle
None of this is an argument in favor of a fork. Even if what you write were
true (and that hasn't been my impression), somebody would still have to do the
work of improving QtWidgets even further. They might as well do that work in
Qt itself without producing a fork.

It's obvious judging from other comments in this thread that Qt has some
problems making people unhappy. However, where those problems are genuine, the
author's energy would be better spent to fix those inside Qt rather than
creating a new project/fork. (If the goal is actually to help other
developers; of course, if all the author wanted was to create an interesting
proof of concept, then more power to them.)

~~~
0xFFC
no fence , but do you understand what he/she talking about ? Qt (simply) does
not allow any changes to Qtwidget code base's . (If I remember correctly) they
even freezed Qtwidget API.

~~~
nhaehnle
What on earth are you talking about?

Take a look at the repository mirror here, for example:
[https://github.com/qtproject/qtbase/](https://github.com/qtproject/qtbase/).
You can easily see plenty of commits that change src/widgets.

Seriously, please point to where you get these ideas from, because they're
just extremely odd and surprising, seemingly coming out of nowhere as if
somebody were spreading FUD.

(One theory that I have is that there may be confusion about the API and ABI
compatibility guarantees that Qt makes. If you're not used to the C++ way of
doing things, it's easy to misunderstand their policy. I assure you that there
are no artificial limitations to changes in Qt, and if you have concrete
grievances with something you should try and get it fixed _inside_ Qt just as
with any other open source project.)

------
scrollaway
Why?

And why 4.8? The 5.x branch is a far better version of Qt.

This looks ridiculous. Qt is a massive framework - the work of hundreds, if
not thousands, of people - and this seems to be the work of a random dev with
zero backing and a 2004-style website with zero content (everything, even the
14-forum completely empty phpbb forum).

~~~
IshKebab
There are some downsides to Qt5.

* It's huge - something like 30 MB for "hello world" on Windows.

* Deployment is a nightmare (loads of plugin DLLs, there's some crazy path stuff going on, if you use QML you have to include a load of system qml files). There is a windeployqt tool which helps but it still isn't as easy as with Qt4.

* QML/QtQuick are very nice for some things, but in a lot of ways they kind of suck. E.g. passing data between C++ and Javascript is always a pain. Also most of the QML tools (compiler, usable GUI editor, profiler, etc.) are only in the enterprise version of Qt.

Having said that, I don't know why they didn't just base it on Qt5, remove all
the QML stuff and make unicode optional (unicode support costs about 20MB).
Qt5 already uses C++11 syntax for signals and slots (though you still need
moc).

I don't know why you dislike their website.

~~~
coldtea
> _It 's huge - something like 30 MB for "hello world" on Windows._

First, 30MB for "hello world" doesn't mean it will get linearly bigger as code
grows. Most is one time off overhead. Else something like Kate would be an 1
TB binary.

Second, 30MB hasn't been an issue since 2002. Heck, I have 20+ apps, each over
30MB, on my PHONE.

~~~
nadams
> Second, 30MB hasn't been an issue since 2002

Back in 2004 a demoscene group created a FPS in 96kb -
[http://www.pouet.net/prod.php?which=12036](http://www.pouet.net/prod.php?which=12036)

That 96kb includes textures, engine and music. No they aren't downloading
content or streaming from the internet. I know how they did it - and with some
tweaking of gcc command line parameters you can write C you can get close to
those file sizes.

When I see that the game RAGE, while an excellent game, takes up 20GB of disk
space I just shake my head. Now I'm not advocating that everyone should be
making FPSes at 96kb - but I feel like 20GB is a little unnecessary for the
game RAGE (especially how short it was).

I personally try to be as efficient as possible when it comes to using other
people's storage and memory.

~~~
scrollaway
That is a phenomenally ridiculous comparison. They are doing procedural
textures/audio etc. RAGE is 20GB because it has a massive amount of high
resolution textures, meshes and audio.

Nothing to do with the libraries they use.

------
tenfingers
Can somebody comment on the experience between transitioning from 4.8 to 5.x?

I didn't see any massive advantage, and the performance of my native UIs,
after porting some large projecs, were negatively affected on both Linux and
Windows (that is, qt 5 added significant overhead without any user-facing
benefit).

I don't know what to think about QtQuick/QML, I feel like I see no significant
use for them. It sounds nice to be able to push dumb logic into the UI, but
then again UI and code are often tied together to the point that there's a
limit of what can be done without becoming a state synchronization burden.
It's also slower, which brings me to my first point.

Even though Qt5 has polished some edges, the project being based on 4.8 "rings
home" to me.

~~~
x5n1
I am happy Qt is still being maintained. But yes same experience, going from
the 4.x branch to the 5.x branch seemed to slow things down.

------
CrLf
The last time I used Qt was a long, long, time ago. I liked it, mainly because
it avoided the STL and was cleaner. I'm not a fan of C++ (I consider it a
baroque and overly complex language), but I enjoyed using Qt.

So, this line seems like a drawback to me, instead of an advantage:

"CopperSpice is a C++ library derived from the existing Qt 4.8 framework. Our
goal was to change the core design of the libraries, leveraging template
functionality and C++11 capabilities."

~~~
cmrdporcupine
Well you should take another look at C++. The changes in the language in the
last 10 years have really made it more pleasant to work with, in particular
around the STL (which imho is excellently designed, but was hampered by the
the language itself.)

There was always a kernel of a beautiful language inside C++ trying to get out
(and it wasn't C). I think the recent moves within the language have started
to expose it.

FWIW I have approached Qt many times and always been repulsed by its non-
standard use of C++. It felt very much like the project had to be built around
Qt -- with their nonstandard preprocessor, lack of embrace of the STL, etc --
rather than Qt fitting itself into existing C++ projects. I'm very picky about
the style and structure of my code and I always felt like Qt imposed a huge
proprietary overhead on that front. So I've avoided it. If Qt can finally drop
moc, and use C++11 features, I might consider it.

~~~
CrLf
My perception of Qt may be based on outdated information, but not my
perception of C++. It has too many features, a too high probability of two C++
programmers having chosen a different subset of the language to work with and
thus barely understand each other's code.

What I liked about Qt was exactly how it used nothing from C++ but the core
language, adding a Java-like API on top. Non-standard was a good thing.

------
simfoo
Being one of the few developers who doesn't like the direction Digia went with
Qt in the 5.x versions I welcome this

------
hobarrera
> The redesign allowed us to completely remove the Qt Meta-Object Compiler
> (moc) system.

I recall having heard that this was one of the new goals for Qt now that we
have C++ 11.

Is the intention of this fork to merge back at some point? I don't see the
fragmentation working out for everyone in the long run.

~~~
sirspudd
It is Qt 4.8 based, there is clearly zero intention of remerging it. They
changed the build system!

There are lots of people seeking to repackage Qt's work, add their own spin
(pittance of work) and then attempt to profit off of it as a discrete product.

~~~
asermersheim
CopperSpice is a fork of Qt 4.8 but we have evolved considerably past the Qt
version we started from.

We switched the build system to autotools in order to get away from the
brittle and complex bootstrap system that Qt must maintain.

With respect to your comment about 'a pittance of work' here are some current
numbers from CopperSpice:

43426 files changed, 2062325 insertions(+), 7974133 deletions(-)

Since CopperSpice is an open source project released under the GPL & LGPL, we
are not looking to profit from it nor can we. Now, if someone throws money at
us, we certainly will not refuse. But we did this for the love of the game.

------
cpp098
great! could you explain in detail why you want to replace MOC:

"The redesign allowed us to completely remove the Qt Meta-Object Compiler
(moc) system. Moc is a code generator and did not support many aspects of C++
including templates, complex data types, static type checking, and relies
heavily on string comparisons. Removing moc improves run time performance,
reduces the complexity of the build process, and allows more issues to be
detected at compile time."

~~~
zanny
Just as someone who uses Qt every day... because its kind of a mess? You
already have your compiler preprocessor and the moc is an extra step ahead of
that. When the language didn't support templating that made the moc necessary,
but nowadays you can do signal / slots the Boost way with templates and
without a framework-specific preprocessor to mangle the source files into a
string comparison nightmare.

Maybe in the purest sense the fact you cannot just do g++ <qt-program.cpp> -o
<binary> kind of sucks. It just makes the whole build process implicitly
complicated, and I haven't manually messed with the moc in five years so I've
pretty much forgotten the syntax of baking it into homebrew makefiles.

------
dman
Wanted to add this link by a Krita developer describing their experience
porting from Qt4 to Qt5 -
[http://www.valdyas.org/fading/index.cgi/2015/04/06#portingkr...](http://www.valdyas.org/fading/index.cgi/2015/04/06#portingkritaqt5)

------
janoc
Uhm, "modern" and "built using GNU Autotools" in a single sentence just
doesn't compute.

Cross-platform portability obviously isn't their goal.

Oh and thank you for removing moc and replacing that with some template black
magic. Yeah, you can do that, but your developers are going swear up a storm
at you once they see the wonderful compilation errors that e.g. MSVC produces
with templates ... But I guess they don't target professional Windows devs (cf
the MinGW compilation ...).

This looks very much like a classic not-invented-here syndrome project -
"let's make something better by throwing out everything that made it useful".

I do wonder what is the raison d'être of this project.

~~~
easytiger
> Uhm, "modern" and "built using GNU Autotools"

Autotools represents a pragmatic solution to a non trivial problem. What's
your solution? Hipster like complaining? Perhaps the c/c++ eco system is too
easy and straightforward for the hipster developer class?

~~~
berkut
Use something like CMake which is cross-platform, works very well in most
cases and a lot of cross-platform open-source C++ libs are using already.

~~~
punch_card
CMake. Making easy things easy and hard things impossible. Provided most cases
are easy, an acceptable solution.

~~~
janoc
Hmm, any examples for the impossible hard things? Or are you just trolling?

~~~
berkut
I think CMake is one of the best (not saying it's perfect) C/C++ build systems
I've used (used jam, make, automake, qmake, scons quite comprehensively,
either via choice or under duress), and there are some things that are close
to impossible (or were a few years ago).

One of these was getting an executable that's built as part of a script to
generate a .cpp which is then built as another lib as a further dependency
within the same build - I believe that's possible now as OpenEXR does it.
Similarly, I've had to run external programs that binary patch executables and
had serious issues doing that.

~~~
janoc
That isn't all that hard to do, CMake routinely supports this for e.g. Swig or
Qt's moc/uic/rcc tools. The code generator creates a bunch of files and those
can be either built as a library or added to your normal list of sources.

------
sqeaky
I find the lack of source control access the largest red flag. Where is their
link to Github or something similar?

Maybe I missed it, but I would expect it to be on the download page.

------
ehvatum
Presumably, Digia is following the money with their emphasis on Javascript
smartphone stuff. Qt taken as a whole is profitable for Digia, I have heard.

However, it's very clear that the effort directed towards Javascript on
smartphones is effort not directed towards long-pressing desktop C++ Qt
issues. Lack of QPainter OpenGL core profile support, for example. Because OS
X GL compatibility profile supports almost nothing beyond OpenGL 2.1 and
QPainter can only work in compatibility profile, a cross platform application
that wants to draw into the same OpenGL context with straight OpenGL calls and
QPainter is limited to OpenGL 2.1.

This absolutely sucks. Of course, the javascript stuff works with GL core
profile - because the effort that should have gone into QPainter instead went
into stuff relevant to the javascript-land. Digia is well aware of the issue:
[https://bugreports.qt.io/browse/QTBUG-33535](https://bugreports.qt.io/browse/QTBUG-33535)
WONTFIX, because out-of-scope. It's out of scope because anything that isn't
directly and urgently required by the Javascript adventure is out of scope, I
worry.

The changes required are not so complex as the WONTFIX excuse would imply.
Almost all of the shader code that has to be updated to replace/remove legacy
calls is contained in one file:
[https://github.com/qtproject/qtbase/blob/dev/src/gui/opengl/...](https://github.com/qtproject/qtbase/blob/dev/src/gui/opengl/qopenglengineshadersource_p.h)
Most of that file is not GLSL. The GLSL that is there is mostly boilerplate.

It turns out that QPainter GLSL drawing is actually elegantly implemented and
quite straightforward, especially in comparison to how Windows did "GPU
accelerated" drawing last I looked (during the Vista days). I made decent
progress with my first hack-and-slash attempt to implement core profile
support in just an hour.

How about a Metal backend? And a Vulkan backend? Will QtWidgets ever have
either? I have been getting a lot of signals that, indeed, QtWidgets is the
past, and "NO, why don't you try javascript? How about Javascript? In
addition, Javascript. It's Javascript you're looking for, friend." Never mind
that Qt Quick Controls are currently extremely limited...

If Digia is not, in fact, making money on the Javascript side and is making
money from the desktop and enterprise C++ side, I would gently suggest that
more consideration should be made of the needs of existing paying customers.
If Javascript really is paying the bills, then great. I'll continue not liking
it, but at least the decision to go all-in on Javascript would be rational.

PS, I would welcome any tips for getting a GL 4.1 context texture into a GL
2.1 context on OS X without passing the texture through main memory...

------
cpp098
Will Qt become over-complex as C++11 itself if add more c++11 element?

------
meir_yanovich
great work! but i wander .. What is the purpose of this ? is the license is
still LGPL ? if yes so ...?

~~~
zanny
> What is the purpose of this ?

Its a fork of Qt by a guy who wants to see how much cleaner you can make the
framework using a modern version of the language, it seems.

Maybe it might be merged back upstream at some point to reduce complexity in
the parent project, which would be nice.

~~~
asermersheim
> Its a fork of Qt by a guy who wants to see how much cleaner you can make the
> framework using a modern version of the language

A very astute observation. Actually, it's a fork of Qt by a girl and a guy but
the rest of your statement is spot on.

There is no way we could merge back upstream, but that is not because we
forked from 4.8. It is because statements made by several key individuals in
the Qt project indicate that our changes would not be welcome and they see no
reason to remove moc.

