Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CopperSpice, a Modern C++ Fork of Qt

copperspice.com

Post reply on HN
Print view View original

91–100 of 104 posts

Re: CopperSpice, a Modern C++ Fork of Qt

#91

Post by asermersheim »

zanny wrote: post #55
meir_yanovich wrote: post #2

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

> 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

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.

Re: CopperSpice, a Modern C++ Fork of Qt

#92

Post by scrollaway »

asermersheim wrote: post #87
scrollaway wrote: post #63

Earlier quoted context omitted.

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.

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…

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.

Re: CopperSpice, a Modern C++ Fork of Qt

#93

Post by asermersheim »

janoc wrote: post #17

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 t…

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.

Re: CopperSpice, a Modern C++ Fork of Qt

#94

Post by coldtea »

ci5er wrote: post #82
coldtea wrote: post #27

Earlier quoted context omitted.

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

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

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

Re: CopperSpice, a Modern C++ Fork of Qt

#95

Post by IshKebab »

coldtea wrote: post #27
IshKebab wrote: post #8

Earlier quoted context omitted.

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

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

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.

Re: CopperSpice, a Modern C++ Fork of Qt

#96

Post by IshKebab »

Qwertious wrote: post #59
purerandomness wrote: post #48

Earlier quoted context omitted.

How large do you think is a "Hello World" app that uses .NET?

Well, considering that anything that uses .Net will by definition have .Net as a dependency, at least the size of .Net.

.Net apps don't usually bundle the runtime with them. Qt apps have to.

Re: CopperSpice, a Modern C++ Fork of Qt

#97

Post by IshKebab »

joezydeco wrote: post #50
IshKebab wrote: post #8

Earlier quoted context omitted.

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

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.

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.

Re: CopperSpice, a Modern C++ Fork of Qt

#98

Post by janoc »

berkut wrote: post #69
janoc wrote: post #36

Earlier quoted context omitted.

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…

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.

Re: CopperSpice, a Modern C++ Fork of Qt

#99

Post by janoc »

asermersheim wrote: post #93
janoc wrote: post #17

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 t…

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…

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.

Post reply on HN