CopperSpice, a Modern C++ Fork of Qt

http://www.copperspice.com/

by ingve • 11 years ago

110 95 11 years ago

copperspice.com

meir_yanovich• 11 years ago

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

pavanky• 11 years ago

You can't change GPL licenses by forking the original sources. You will need to have a rewrite.

zanny2• 11 years ago

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.

scrollaway7• 11 years ago

No chance of it being merged back upstream. It's based on 4.x.

asermersheim5• 11 years ago

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.

scrollaway7• 11 years ago

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).

fla2• 11 years ago

I fail to understand either, but they say:

CopperSpice has been modified to remove moc, the Qt meta object compiler. Moc was removed to simplify the build process, allow CopperSpice to be a standalone library, increase run time performance, and allow developers to utilize C++11 features.

So they replaced the moc functionality with some c++11 magic ?

zerr2• 11 years ago

So they replaced the moc functionality with some c++11 magic ?

You mean they replaced moc magic with C++11?

pgeorgi• 11 years ago

So they replaced the moc functionality with some c++11 magic ?

Given that signals and slots were already implemented with templates in 2002 or before (see http://ftp.gnome.org/pub/GNOME/sources/libsigc++/1.0/), there's probably no need for c++11 magic.

guruz• 11 years ago

Indirectly related blog post: "Can Qt's moc be replaced by C++ reflection?"

http://woboq.com/blog/reflection-in-cpp-and-qt-moc.html

IshKebab4• 11 years ago

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.

scrollaway7• 11 years ago

QML/QtQuick etc are modules in Qt 5, you don't have to depend on them at all and they're not linked in. QtCore is tiny.

coldtea2• 11 years ago

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.

joezydeco• 11 years ago

When you begin to get serious about app size using Qt (especially when you're on embedded) you configure and compile the libraries from scratch instead of pulling the SDK libraries in.

I can typically get under 6MB on ARMv7. Nothing to brag about, but if you want a demoscene-sized app targeted for a single architecture you aren't using Qt anyway.

mmozeiko• 11 years ago

Afaik if you don't need WebKit then you can disable icu when building Qt - use "--no-icu" when running configure. Not sure exactly how much it will disable, but it will free you from depending on icu libraries for core libraries

DocSavage• 11 years ago

The lack of a public repo of some kind and obvious licensing makes this a no-start for me.

dudifordMann• 11 years ago

so source is available, though not hosted in a VCS: http://download.copperspice.com/copperspice/source/

Legal info is also available. http://www.copperspice.com/docs/cs_overview/legal.html

So it's just not in github-esque hosted format you're expecting.

asermersheim5• 11 years ago

We had everything set up on sourceforge and we hit the limits of what we could accomplish on sourceforge last month.

We have been moving everything including downloads and forums to a better location. We have not yet moved the git repo to a publicly accessible location, but this is in progress. Thank you for bringing this to our attention, and I apologize for the inconvenience.

emddudley• 11 years ago

The About page [1] lists two people: Barbara Geller and Ansel Sermersheim.

[1] http://www.copperspice.com/about.html

codeshaman• 11 years ago

I'm always bewildered by such aggressive reactions to things people put out for free.

So you don't like it and won't use it, but why do you find it necessary to insult the people who worked on it ? Are they trying to steal something from you or cheat you into giving up your freedom or something ?

I just don't get it. We are all developers and we all know how hard it is to make something.. anything. And knowing the struggle I go through to get things to completion, I have great respect for people who actually finish things and share them with the world.

Even if I won't use the thing and find it useless, I still think they deserve at least a word of support, not a dismissive rant.

scrollaway7• 11 years ago

why do you find it necessary to insult the people who worked on it

I insulted the work, not the people who worked on it. And I didn't gratuitously insult it, I've given further reasoning elsewhere in the thread: 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.

It wasn't aggressive. It certainly was negative. But from what I've seen, this was never a space where your project will be cuddled. Nor is open source in general a place you get a free ride just because "you don't have to use it if you don't like it".

When one puts their work forward, it's either to either receive criticism on it or popularize it. In either case, negative criticism is a good thing.

Like I said, I didn't criticize it just to be negative - if you go through my previous posts, you'll find that I try to be overwhelmingly positive, even to projects I find pointless. But this here is not "just pointless", it's a fork. Forks are divisive, and this is a fork which does not bring any net positives and which has no way of ever being merged back into the project, given that it's based on an outdated version and model of Qt.

sqeaky2• 11 years ago

The project is large, but superficially seem to have a reasonable approach and documentation. The website looks fine as a simple communication tool and changelog.

Why attack them for their style and not something substantive?

seletz2• 11 years ago

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• 11 years ago

Seems to be all here: http://www.copperspice.com/docs/cs_overview/index.html

seletz2• 11 years ago

Duh, OK. My bad.

cjslep3• 11 years ago

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

frozenport• 11 years ago

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• 11 years ago

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.

pjmlp3• 11 years ago

So will Qt stop supporting commercial UNIX compilers and embedded platforms with compilers still stuck in C++98/03/partial 11?

cjslep3• 11 years ago

Embedded system support is very much a high profile concern, and is definitely on Lars Knoll's radar. Given their enthusiasm, I would not start any doomsday rumors.

joe_the_user• 11 years ago

I recall that Qt 5.0 involved something of a turn toward Qml and maybe implied a gradual obsoleting of the entire old QWindow/QWidget hierarchy (not that this has happened but the "focus is on a new way of programming" according to the blogs of the time). So there's some logic in forking there. Qt 5 is web-fusion, integrated webkit everywhere and this for those oriented to plain old GUI windows forever.

I still couldn't say whether this is a good idea.

jmgao• 11 years ago

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.

Liberal usage of static_assert can make your life much less painful. For the specific case you mentioned, static_assert(std::is_base_of<QObject, T>::value, "Type does not inherit from QObject") gives you a reasonable error message (unfortunately, there's no way to stringify a template argument in the error message (yet?), but your compiler should show you where the class is being instantiated)

janoc6• 11 years ago

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• 11 years ago

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?

janoc6• 11 years ago

Before you call someone "hipster", I suggest you actually learn something about the problem.

CMake is the defacto standard for building portable C/C++ software today, there is also SCons. In fact, Qt includes its own build system called qmake. All of these offer much more than the GNU Autotools ever did.

So why do these things exist when autotools are so wonderful? Well, autotools are a damn nightmare to maintain (m4 scripts anyone?) and next to impossible to use outside of the GNU ecosystem - try to use it on Windows or Android without crutches like MinGW or Cygwin.

Basically, an autotools build system is pretty much unusable except on a POSIX/Unix-like platform and even then it handles only building of the package. Not a proper installation support (e.g. support for installer building/packaging), no tests, no continuous integration/compile farm support, poorly written m4 code breaks parallel compilation, etc.

berkut2• 11 years ago

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.

lmm2• 11 years ago

Cross-platform portability obviously isn't their goal.

As someone who runs a couple of obscure platforms, I swear every time I have to use a non-Autotools project. Autotools may be slow and may check for seventeen different fortran compilers even if your project never uses fortran, but portability-wise it simply works.

janoc6• 11 years ago

I suggest that everyone defending Autotools in this day and age actually reads one of these blogs (and check the date on them!):

http://freecode.com/articles/stop-the-autoconf-insanity-why-...

http://www.shlomifish.org/open-source/anti/autohell/

That should give you the idea why Autoconf/Automake setups are past their sell-by date. For more than a decade.

asermersheim5• 11 years ago

Cross platform portability is a major goal of the CopperSpice project. Autotools may be old but it still beats its competitors for portability to obscure platforms.

We have removed moc and added templates but it is by no means black magic. The complexities are below the surface and we worked very hard to create a clean API for developers.

Since you mention you are on MSVC which is a bit behind the curve in standards compliance, you may be unaware of the wonderful tools that C++11 now provides for generating simple and readable template error messages. We have made extensive use of static assertions for specifically this reason. The vast majority of errors are quite straightforward.

As a bonus, many conditions which are run time errors in Qt are caught and diagnosed at compile time in CopperSpice. I will take a compile error, however inscrutable, over a guaranteed runtime failure any day.

janoc6• 11 years ago

Well, unfortunately the fact the clang/llvm generates nice looking error messages doesn't help Windows developers using Visual C++ at all.

And obscure platforms - are you targetting those as a priority? That could explain your choice of build system. On the other hand, the obscure platforms tend to have old, noncompliant C++ compilers and STL, so I am not completely sure how is that going to work together with your C++11 requirement. For me an "obscure platform" would be something like an IRIX 6.5, Solaris or some embedded hardware. Good luck with requiring C++11 there.

Of course, you could be targeting an obscure platform in the sense that it is one of the few that actually ships with fully C++11 compliant compiler, but then good luck with wide adoption of your software ...

Re compile errors vs runtime errors - agreed, even though most runtime errors related to moc in Qt are things like connecting to non-existing slot. That generates only an error message in console/log, it is not a fatal error.

However, moc gets you faster compilation time (heavily templated C++ takes ages to compile - just look at Boost) and more readable/idiomatic code. And then there is the portability issue to older compilers - templates were traditionally the poster child for poor/incomplete implementations by the compiler vendors.

cpp0983• 11 years ago

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."

zanny2• 11 years ago

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.

hobarrera• 11 years ago

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• 11 years ago

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.

asermersheim5• 11 years ago

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.

CrLf2• 11 years ago

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• 11 years ago

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.

CrLf2• 11 years ago

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.

eklavya• 11 years ago

<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.

scrollaway7• 11 years ago

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.

dman3• 11 years ago

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.

asermersheim5• 11 years ago

We just found out about this thread 10 minutes ago, and we have been on reddit for the past 8 hours answering questions. We are stunned by the level of interest and feedback.

We have been using git from day 1 in house for our version control and that will be available to the public shortly.

We have been focusing on outreach to the local SF Bay area developer community, and we presented CopperSpice at the SF Bay Area Association of C/C++ users meeting in February. You are welcome to peruse the meeting notes and our slides:

http://www.meetup.com/SFBay-Association-of-C-C-Users/events/... https://docs.google.com/presentation/d/1Sxei-Em6cnYbE0Zj16j6...

In terms of 'backing any of it up', the code speaks for itself. I am happy to answer any specific questions you may have.

sqeaky2• 11 years ago

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.

simfoo• 11 years ago

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

tenfingers• 11 years ago

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• 11 years ago

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.

cpp0983• 11 years ago

I think QtQuick/QML are mainly used for mobile applications

cpp0983• 11 years ago

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

ehvatum• 11 years ago

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 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/... 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...

dman3• 11 years ago

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...

CopperSpice, a Modern C++ Fork of Qt

Related Stories