CopperSpice, a Modern C++ Fork of Qt(copperspice.com)
copperspice.com
CopperSpice, a Modern C++ Fork of Qt
http://www.copperspice.com/
103 comments
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...
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...
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...
great work! but i wander ..
What is the purpose of this ?
is the license is still LGPL ? if yes so ...?
You can't change GPL licenses by forking the original sources. You will need to have a rewrite.
> 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.
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.
> 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.
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.
No chance of it being merged back upstream. It's based on 4.x.
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).
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).
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.
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.
> 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.
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.
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.
* 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.
>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.
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.
> 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
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.
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.
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.
Nothing to do with the libraries they use.
[deleted](2)
Heck, I have 20+ apps, each over 30MB, on my PHONE.
I don't recall most smartphone OS being well known for intelligent resource utilization.
I don't recall most smartphone OS being well known for intelligent resource utilization.
> Second, 30MB hasn't been an issue since 2002. Heck, I have 20+ apps, each over 30MB, on my PHONE.
Good for you?
That doesn't mean that it is not an issue.
Good for you?
That doesn't mean that it is not an issue.
>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.
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.
Of course it doesn't grow linearly, but 30 MB is a huge up-front cost. If you're writing a simple app - or even a relatively complex one - users on slow connections will be a bit annoyed.
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.
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.
How large do you think is a "Hello World" app that uses .NET?
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.
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.
Yeah... that is a pretty huge pain though. Also there are more licensing issue with static linking - you have to distribute the .o files etc.
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.
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
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 ?
> 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 ?
> So they replaced the moc functionality with some c++11 magic ?
You mean they replaced moc magic with C++11?
You mean they replaced moc magic with C++11?
I didn't realize the c++11 standard could make it possible to get rid of moc. Defenately better this way around ;)
I can't wait to see this happening upstream for Qt5.
I can't wait to see this happening upstream for Qt5.
moc magic for signals/slots was already possible with C++98, as proven by Gtkmm already back in 2000.
http://libsigc.sourceforge.net/
But it required beefy template support, which would leave out some of the compilers supported by Qt (not only MSVC).
http://libsigc.sourceforge.net/
But it required beefy template support, which would leave out some of the compilers supported by Qt (not only MSVC).
Advanced template metaprogramming is far less common of a skill than opening a generated source file and reading source code.
C++ is a far more common skill than moc. I know C++, I can barely get my head around writing a Qt app.
Exactly , Even if TMP is much harder than MOC, TMP is standard , by forcing people to learn it they are not doing something wrong or ridiculous , but by forcing people to learn something specific to framework we are doing something wrong in my opinion {then why should we have standard at first place ? every one can create its own C++ }
Well, one of the aim of C++11 (and 14) is to make template metaprogramming much easier.
To the user it shouldn't matter wether you use a moc DSL or a template DSL. If you're a developer, you'll have to learn the innards of the moc on top of C++, which already contains templating anyway. When I first saw the signal/slot API, I wondered how they solved it and was dissappointed that they used a standalone tool for something that could've been solved with standard C++.
> 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.
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.
Indirectly related blog post: "Can Qt's moc be replaced by C++ reflection?"
http://woboq.com/blog/reflection-in-cpp-and-qt-moc.html
http://woboq.com/blog/reflection-in-cpp-and-qt-moc.html
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?
Why attack them for their style and not something substantive?
The lack of a public repo of some kind and obvious licensing makes this a no-start for me.
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.
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.
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.
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.
The About page [1] lists two people: Barbara Geller and Ansel Sermersheim.
[1] http://www.copperspice.com/about.html
[1] http://www.copperspice.com/about.html
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?
- 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?
Seems to be all here: http://www.copperspice.com/docs/cs_overview/index.html
Duh, OK. My bad.
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
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
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.
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.
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 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.
I still couldn't say whether this is a good idea.
> 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)
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)
So will Qt stop supporting commercial UNIX compilers and embedded platforms with compilers still stuck in C++98/03/partial 11?
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.
Another point to remember is that clang is changing the calculus of C/C++ compiler support in embedded. There are a lot of embedded systems (QNX comes to mind) that are switching to clang and getting very modern C/C++ support.
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.
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.
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.
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.
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.
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.
> 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?
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?
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.
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.
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.
CMake. Making easy things easy and hard things impossible. Provided most cases are easy, an acceptable solution.
Hmm, any examples for the impossible hard things? Or are you just trolling?
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.
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.
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.
> 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.
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.
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.
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.
I'm not unaware of those. Much of the first article's claims are simply false, and the second article's claims that CMake breaks less often than auto* are, uh, not borne out by my experience. (CMake is by no means the worst though; if you must use something non-autotools CMake is probably the best option). The facts simply don't match the rhetoric.
CMake is so wonderful. There's no reason to use it over autotools.
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."
"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."
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.
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.
> 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.
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.
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.
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.
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.
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.
[deleted]
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."
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."
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.
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.
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.
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.
<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.
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.
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.
The negativity really shouldn't be a surprise.
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.
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.)
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.)
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.
What on earth are you talking about?
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.)
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.)
[deleted]
The QWidgets API seemed to work just fine the last time I touched it. I'm not unhappy. I see no reason for a fork.
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.
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.
Many serious desktop bugs remain unfixed. Perhaps if there was less of a stress on new features, there would be more bandwidth to fixing existing bugs. Here is an example bug - drag and drop with filenames is broken out of the box on Yosemite and has been for quite a while - https://bugreports.qt.io/browse/QTBUG-40449 .
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...
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...
Fair enough; I was under the impression that the situation was far less serious.
Dont be surprised but development of widgets/core libraries wasn't stopped, just fetch qtbase and inspect git logs.
Keep in mind that there is QtCreator which based on QtWidgets and unlikelly will be based on something else. What kind of styling, qss?
What new widget class do you need?
What new widget class do you need?
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.
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.
Ok, I went through your presentation, it does give more background. Let me re-raise my concerns.
- 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.
- 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.
I am not any of developer of this project , but for first concern I think most C++ bug fix'es can back ported very simply to 4.8, I think most of them already done by Qt itself.
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.
Maybe I missed it, but I would expect it to be on the download page.
Being one of the few developers who doesn't like the direction Digia went with Qt in the 5.x versions I welcome this
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.
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.
Will Qt become over-complex as C++11 itself if add more c++11 element?