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.
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.
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'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)
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.
- 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.
<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.
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.
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.)
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.
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.)
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.
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 .
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?
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:
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.
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.
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.
> 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.
* 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).
>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.
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.
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.
> So, now you need your artists to be programmers.
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").
Here's the thing: Procedural rendering is a tool. It's useful in some cases (like, say, randomly generating massive universes with distinctive patterns a la elite, minecraft, etc). It's useless if you want to do predictable things which obey a designer's vision. Going from concept art/blueprint to a live mesh is completely impossible with the tooling we have today to do procedurally.
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.
>Downloading that 20GB RAGE game has turned into quite a challenge
Dated First World problems notwithstanding I immensely enjoy the harping on RAGE, especially the fixation on the assets (and the resulting download size). GTAV is nearly 60GB and is immensely popular. It uses a traditional texture model compared to the Megatexture technique used in idtech. Computing the quantity of textures on install would result in people remarking how long it takes to install instead of download.
> 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.
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.
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.
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
> 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 ?
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++ }
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++.
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?
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.
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.
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."
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.
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.
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.
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.
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."
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.
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.
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'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.
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.
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.
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.
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.
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.
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...
> 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.
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