3 ms·

This is a pretty cool approach. I never understood the rationale behind CopperSpice, especially not why they felt the need to fork the entire codebase instead o

This is a pretty cool approach. I never understood the rationale behind CopperSpice, especially not why they felt the need to fork the entire codebase instead of trying to work within the boundaries of Qt itself. They've also done the same thing with Doxygen, I believe. [1] But seeing that the CopperSpice version of an executable is 115mb vs 16mb with regular Qt and with Qt+Verdigris should make it clear this is "the way to go". Personally I don't necessarily dislike moc so I won't be using it, but if you're really averse it seems nice enough. [1] http://www.copperspice.com/documentation-doxypress.html http://www.copperspice.com/documentation-doxypress.html

dguaraglia 10y ago
I'm going to go ahead and guess that the only way the CopperSpice executable is 115mb is by doing a static linking with no dead code removal of all of QT, vs. dynamic linking for QT and Verdigris. Not sure if that's a requirement of CopperSpice or what, but I'm not sure we are comparing apples to apples in this case.
e12e 10y ago
> I never understood the rationale behind CopperSpice, especially not why they felt the need to fork the entire codebase instead of trying to work within the boundaries of Qt itself. They actually go into this in the introduction of their CppCon '15 talk: "CppCon 2015: Barbara Geller & Ansel Sermersheim “CopperSpice: A Pure C++ GUI Library"" https://m.youtube.com/watch?v=LIiwBNvTllk https://m.youtube.com/watch?v=LIiwBNvTllk I don't quite get it either - they appear afraid of the contributer agreement - but I don't get it. So what if a contribution ends up in a closed source product; it's not like they could revoke the rights to code already published; the worst that could happen is that the community would have to fork if/when the at project discontinued the free licenced part (see open solaris).
- ericfrederich 10y ago
  It seems they wren't happy with the bootstrapping process which involved a lot of ifdefs either. They claim to have cleaned up a lot of the code base by not involving moc.
educar 10y ago
CopperSpice is a good thing. If you follow the Qt mailing list, there are good debates on the approaches and it's pushing Qt ahead in good ways (like Verdigris itself). The Qt team was unwilling to question many of the assumptions that are built into Qt (like moc) and now the existence of CopperSpice pushes them to reconsider.
VSChawathe 10y ago
Qt/KDE seems targeting polyglots onto Quick JSON/QML+ECMAscript/WebAssembly heavily influenced by http://merproject.org/ http://merproject.org/ , whereas CopperSpice seems to be continuing from Qt's past Widgets/native C++. Verdigris is at best an isolated small step for those unwilling to head toward Qt's monotonous direction. IMHO Qt's big enough that competing CopperSpice fork will only be beneficial.

dguaraglia 10y ago

I'm going to go ahead and guess that the only way the CopperSpice executable is 115mb is by doing a static linking with no dead code removal of all of QT, vs. dynamic linking for QT and Verdigris. Not sure if that's a requirement of CopperSpice or what, but I'm not sure we are comparing apples to apples in this case.

e12e 10y ago

> I never understood the rationale behind CopperSpice, especially not why they felt the need to fork the entire codebase instead of trying to work within the boundaries of Qt itself. They actually go into this in the introduction of their CppCon '15 talk: "CppCon 2015: Barbara Geller & Ansel Sermersheim “CopperSpice: A Pure C++ GUI Library"" https://m.youtube.com/watch?v=LIiwBNvTllk https://m.youtube.com/watch?v=LIiwBNvTllk I don't quite get it either - they appear afraid of the contributer agreement - but I don't get it. So what if a contribution ends up in a closed source product; it's not like they could revoke the rights to code already published; the worst that could happen is that the community would have to fork if/when the at project discontinued the free licenced part (see open solaris).

ericfrederich 10y ago
It seems they wren't happy with the bootstrapping process which involved a lot of ifdefs either. They claim to have cleaned up a lot of the code base by not involving moc.

educar 10y ago

CopperSpice is a good thing. If you follow the Qt mailing list, there are good debates on the approaches and it's pushing Qt ahead in good ways (like Verdigris itself). The Qt team was unwilling to question many of the assumptions that are built into Qt (like moc) and now the existence of CopperSpice pushes them to reconsider.

VSChawathe 10y ago

Qt/KDE seems targeting polyglots onto Quick JSON/QML+ECMAscript/WebAssembly heavily influenced by http://merproject.org/ http://merproject.org/ , whereas CopperSpice seems to be continuing from Qt's past Widgets/native C++. Verdigris is at best an isolated small step for those unwilling to head toward Qt's monotonous direction. IMHO Qt's big enough that competing CopperSpice fork will only be beneficial.