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

71–80 of 104 posts

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

#71

Post by mmozeiko »

IshKebab wrote: post #8
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).

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

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

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

#72

Post by nib952051 »

dman wrote: post #67
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.

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.

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?

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

#73

Post by joe_the_user »

cjslep wrote: post #10

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

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.

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

#74

Post by CrLf »

cmrdporcupine wrote: post #37
CrLf wrote: post #30

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, levera…

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

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.

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

#75

Post by scrollaway »

codeshaman wrote: post #34
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).

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

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

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

#76

Post by weland »

dman wrote: post #67
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.

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.

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.

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

#77

Post by dman »

weland wrote: post #76
dman wrote: post #67

Earlier quoted context omitted.

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.

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 .

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

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

#78

Post by weland »

dman wrote: post #77
weland wrote: post #76

Earlier quoted context omitted.

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 . Also you just have to go take a look at the comments in the Qt release announcements to see that t…

Fair enough; I was under the impression that the situation was far less serious.

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

#79

Post by nadams »

Qwertious wrote: post #58
[deleted] wrote: post #46

Earlier quoted context omitted.

[deleted]

So, now you need your artists to be programmers. 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. An…

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

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

#80

Post by jmgao »

cjslep wrote: post #10

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

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

Post reply on HN