
Verdigris: Qt without moc - ingve
https://woboq.com/blog/verdigris-qt-without-moc.html
======
royjacobs
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)

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

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

~~~
jdright
> "venomous"

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

~~~
kbenson
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?

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

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

------
jheriko
verdigris... not good for copper :P

