Verdigris: Qt without moc | Hacker News Reader

Verdigris: Qt without moc

woboq.com

80 pointsingve20 comments

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

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.

> 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

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

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.

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.

Qt/KDE seems targeting polyglots onto Quick JSON/QML+ECMAscript/WebAssembly heavily influenced by 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.

This is awesome. Olivier (author of that post) has made some really cool stuff if you go back through their blog posts. Also I wonder if this means the CopperSpice guys will stop development.

I often find myself wishing that Nokia had licensed Qt under the MPL or a custom 'contribute back' license instead of the venomous LGPL. I don't think there's any other framework out there that does all the things Qt does for C++ devs and I'd use it for a lot more things if it had a more reasonable license. Its one thing to expect modifications back (which I complete agree with), but mandating how code can be linked and excluding closed platforms (embedded, mobile) are horrible terms to have to adhere to.

The awesome, is it that this demonstrates a viable way to have a simpler toolchain?

More that I have something to point people that complain about the moc to :)

> "venomous"

More FUD! LGPL is the best license from what you call 'contribute back'.

While the OP shouldn't have used "venemous", calling it FUD, and then calling the target of the insult the "best" in some respect with nothing to back it up is only slightly better from the perspective use useful conversation. How about explaining your rationale behind why LGPL is the best solution and addressing the more rational concerns brought up, so we can move this conversation past the "No, mine is better!" stage?

Because there are other places to discuss this than this thread.

Sure, there are always other places to discuss something, but that doesn't mean this isn't a good place. Some of the best discussions I've seen or been part of here have been tangential to the original post, as discussions drift. I think the bar here is heavily weighted towards useful, instead of relevant, and relevance is almost always debatable.

To be clear, I don't think anyone minds a civil discussion on the LGPL vs BSD licenses, as long as it's also factual. I wouldn't.

FUD! It's a fine place.

I apologize for using a term that is derisive. I'd be fine if contributing back was the only requirement. The other terms however at the very least inconvenience developers in how they build and deploy applications, and at worst simply exclude entire platforms. Therefore, I disagree that LGPL is 'the best' for contributing back because the MPL maximizes utility and potential targets. On the other hand with the additional LGPL terms, I don't see how they improve the 'contributing back' part. They instead extend additional user level freedoms which in my opinion are orthogonal to contribution. I'm not starting a permissive/restrictive flamewar here, both the MPL and LGPL have a very similar flavor so I think its fair to compare them.

Most developers I know use the LGPL only because they want any improvements contributed back and not because they want to restrict linking or platforms. Plenty of LGPL libraries come with linking exceptions, and lots of devs don't even know about potential platform limitations.

I think you can still buy a commercial license.

HN guidelines discourage classic flame war topics. The BSD (and similar) vs GPL license debate is one such topic.

> but mandating how code can be linked and excluding closed platforms (embedded, mobile) are horrible terms to have to adhere to.

Then you buy a commercial license. LGPL is serving it's purpose here just fine. Somebody has to pay for development. This is the incentive.

Sure, that's why I said "I wish". I'm well aware of the $50-300+/month commercial development license. Qt is a high quality product and often worth the price tag. I'm not sure that the original intent of releasing it under LGPL was to use it as a means to push people to go commercial for certain platforms.

In the original announcement for LGPL as a license option:

"Adding LGPL version 2.1 will greatly increase adoption of Qt across Windows, Linux, embedded Linux, Mac, S60, Windows CE, maemo, and Ovi web services. Having a larger number of users, including Nokia developers, providing feedback and contributions will help Qt remain a cutting edge, robust UI and application framework."

To me it seems like the intent was to increase adoption (including in embedded and mobile), but after the recent Digia/Qt Company corporate changes you can tell there's been a shift in the way the LGPL is interpreted. For example, before they had guidelines on their wiki (back when qt-project was still around) on LGPL compliance for mobile platforms that basically said 'Android was okay'... but now if you look at their new guidelines on qt.io after they changed everything, they are pushing for commercial license adoption. I'm pretty sure that was the motivation behind the LPGLv2 -> v3 change as well.

verdigris... not good for copper :P

Reply on news.ycombinator.com