CopperSpice, a Modern C++ Fork of Qt
copperspice.com
copperspice.com
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.
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.
I still couldn't say whether this is a good idea.
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)
- 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?
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.
The negativity really shouldn't be a surprise.
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.)
Take a look at the repository mirror here, for example: 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.)
And I've never used QML, QtQuick and all that. I played with them a little, saw absolutely no point in it, and never really needed them. But the QWidgets API is nice, stable and very well documented.
Also you just have to go take a look at the comments in the Qt release announcements to see that the views I am expressing here are not an isolated case. Here is an example - https://blog.qt.io/blog/2015/03/17/qt-5-5-alpha-available/#c...
What new widget class do you need?
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.
- You are based on Qt 4.x. Why? The 5.x branch is better in every respect (yes, bugs, but that's fixable). This project is breathing life into a version of the lib which really should be dead. I think this is a net negative for Qt.
- Why is this the first most of us in the Qt community hear about it? The project is basically coming out of nowhere, imposing itself as this shiny new thing when it has critical flaws and the only point of contact is an email address and a forum with 0 posts in it. Feels like it was developed in complete secrecy.
- (minor) Autotools build system, really? You're not going to get much respect about this from most Qt devs. Why not just use cmake?
- I'm concerned about the entire way this project came forward. You don't have a git repository. You claim you will but claiming things is easy - the question it immediately raises is why don't you have a git repository yet? (And this comes back to what I was saying earlier about developing this in secret).
The lack of a repository is the second most important issue after 4.x, I think. Git repos aren't just "the code". They're insight into how development happens (are commits clean and readable? is it easy to contribute?), insight into who contributes (is it a corp? how many people are working on this?), into whether upstream changes are being pulled down, etc.
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).
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.
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.
* 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.
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.
Back in 2004 a demoscene group created a FPS in 96kb - 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.
Nothing to do with the libraries they use.
Deleted comment
The decision between prerendered and procedurally generated terrain/textures/etc. is a tradeoff between.. oh, I dunno, developer time, artist time, platform disk space, download time, platform CPU usage, platform graphics usage, and other factors. If you believe game studios have been consistently going for the less optimal choice, then you or someone else could start a studio that makes the better choice, exploit that inefficiency, and gain a market advantage. (Perhaps the demographic of gamers with modern CPUs but 1990s hard drives is ripe for tapping?).
If on the other hand there is no such market potential, then it isn't clear to me in what practical sense the assertion that games 'should' be procedurally generated holds.
I don't think you quite understand what you're asking. The number one rule for high-quality aesthetics in games is that you let the ARTISTS call the shots, with someone in-between to tell them when that's a terrible idea technically. This would break that horribly.
And that's ignoring the load times, which increases massively if you have to procedurally generate it. And having decent level design, which I GUARANTEE will not often pop up naturally in procedurally-generated environments. Meanwhile, disk space is pretty damn cheap and will save you a bunch of time and money.
There is some arguments if you should allow artists to program (Blender does have a built in scripting language).
However, the same group that created the FPS demo also created a tool to create demos - artists can go as wild as they want without needing to write a line of code: http://www.farbrausch.com/prod.py?which=168
If you want something a little more well documented and updated you should check out ZGameEditor - http://www.zgameeditor.org/.
> And that's ignoring the load times, which increases massively if you have to procedurally generate it.
Any reason why you can't render and save the textures on first run? I feel like Natural Selection 2 does that.
> Meanwhile, disk space is pretty damn cheap and will save you a bunch of time and money.
You are forgetting the step in between. Using your argument that disk space is cheap (and assuming they don't use their hard drive to store anything else...) - in the US ISPs are playing a dangerous game. A small DSL provider has a 5GB cap and will charge outrageous fees for going over: http://stopthecap.com/2010/04/14/frontiers-5gb-cap-is-back-n...
Downloading that 20GB RAGE game has turned into quite a challenge (of course you could always use the Valve response of "take your computer to a friends house").
Yes, most games could certainly optimize their contents. I'm certain there's dozens of gigabytes of data which could be shaved off on any gamer's computer between all the installed games, but most of what's in there is there for a reason. Also ... something about frying fish.
So treat that technique as a tool. Not everything is a nail. Is RAGE too large? Maybe. Would procedural generation be appropriate for it (in a way that meaningfully reduces contents size)? Certainly not... not without redesigning the game from the ground up.
> You are forgetting the step in between. Using your argument that disk space is cheap (and assuming they don't use their hard drive to store anything else...) in the US ISPs are playing a dangerous game. A small DSL provider has a 5GB cap and will charge outrageous fees for going over Canadians have been dealing with dinky quotas for awhile and entertainment streamed or downloaded thrives there. In the states there are plenty of people on dial up who live out in the sticks or are on satellite connections and you know what? I'd wager these people aren't the target market. For the vast majority of businesses the most expensive thing is employee overhead. Storage is cheap and getting cheaper, developer time not so much. I appreciate technical efficiency as much as anyone. The reality is that the junk pile is full of technically superior products that died because the competition beat them to market or out marketed them.
>However, the same group that created the FPS demo also created a tool to create demos - artists can go as wild as they want without needing to write a line of code: http://www.farbrausch.com/prod.py?which=168 If you want something a little more well documented and updated you should check out ZGameEditor - http://www.zgameeditor.org/. Neat. I'd sincerely enjoy seeing an attempt at making a game like RAGE with zgameeditor. I see excellent examples of toy tools. Using the right tool for the right job makes a world of difference, take a look at Unreal4, ZBrush, Maya, and a host of others involved in asset pipelines. You'll notice many of these tools are specialized. Pay close attention to the features and compare those to zgameditor.
I don't recall most smartphone OS being well known for intelligent resource utilization.
Good for you?
That doesn't mean that it is not an issue.
When I said "I have 20+ such apps on my PHONE" my intension wasn't to imply I was some lone outlier having those. Rather, that this is the NORM for anyone with a smartphone today.
So, if a billion people are OK with 20+ 30MB+ apps on their phones, it does mean it's not an issue -- and even less so on the desktop, which has 10x or more the storage capacity of a smartphone.
A basic Qt text editor is about 5 times the size of Notepad++. That isn't good. And yes I know why that is the case but that doesn't really excuse it.
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.
> 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 ?
You mean they replaced moc magic with C++11?
I can't wait to see this happening upstream for Qt5.
http://libsigc.sourceforge.net/
But it required beefy template support, which would leave out some of the compilers supported by Qt (not only MSVC).
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.
Why attack them for their style and not something substantive?
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.
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.
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.
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."
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.
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.
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.
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.
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.
"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."
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.
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.
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.
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.
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.
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.
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?
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.
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.
Maybe I missed it, but I would expect it to be on the download page.
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...
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.
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.