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

61–70 of 104 posts

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

#61

Post by dudifordMann »

DocSavage wrote: post #9
scrollaway wrote: post #3

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

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

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.

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

#62

Post by sirspudd »

hobarrera wrote: post #29

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

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.

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

#63

Post by scrollaway »

eklavya wrote: post #47

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

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

#64

Post by tenfingers »

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.

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

#65

Post by scrollaway »

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.

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

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

#66

Post by x5n1 »

tenfingers wrote: post #64

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…

I am happy Qt is still being maintained. But yes same experience, going from the 4.x branch to the 5.x branch seemed to slow things down.

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

#67

Post by dman »

scrollaway wrote: post #63
eklavya wrote: post #47

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

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.

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

#68

Post by cpp098 »

tenfingers wrote: post #64

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…

I think QtQuick/QML are mainly used for mobile applications

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

#69

Post by berkut »

janoc wrote: post #36
punch_card wrote: post #24

Earlier quoted context omitted.

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.

Post reply on HN