
Verdigris: Qt Without Moc - ailideex
https://woboq.com/blog/verdigris-qt-without-moc.html
======
yellow_lead
From my experience using Qt, the MOC wasn't a pain point for me. All the
generations that I saw were very straightforward and I never had to mess with
it.

That's just my experience though, so I'd love to hear where people have found
shortcomings.

Also, I am happy to see this project and may try it out nonetheless. Always
happy to see work around Qt.

~~~
arketyp
The convenience of the MOC is its raison d'être. The minor pain point for me
is practically being forced to use the Qt Creator IDE. I'm happy to see a
possible best of both worlds solution like this.

~~~
likeliv
No need to use Qt creator. Most C++ build systems support moc out of the box,
or with minor adjustments.

~~~
ailideex
I was trying to figure out how to do MOC from gnu make when I came across
this, the only other option I saw was to run qmake and then run that generated
makefile from my makefile. Of those two options verdigris seemed to be the
better choice to me.

~~~
marmaduke
[https://doc.qt.io/qt-5/moc.html#writing-make-rules-for-
invok...](https://doc.qt.io/qt-5/moc.html#writing-make-rules-for-invoking-moc)

Like that?

~~~
ailideex
Thanks, I guess I should have kept on looking.

------
Blackthorn
What's really cool is moc-ng from the same person. As a clang plugin, it gets
around all the limitations from having a separate code generator.

------
ailideex
I really despised having to use moc for QT and I'm glad to have found this, it
works quite well. Needs C++14 though.

~~~
Nicksil
I'm interested in hearing your thoughts on the MOC if you have time and don't
mind sharing. I've been researching QT's software design approach,
architecture, etc. ("core" code base in general), and stand to benefit from
learning the pros and cons of software built this way.

~~~
ailideex
My biggest gripe with MOC is that it makes it no longer C++ and if I just want
to quickly throw together some sample code and build it with a makefile I
can't. This still requires the use of a separate header file with is annoying
but a lot less annoying than writing in a language which is not c++ and which
does not work with a simple toolchain.

~~~
jcelerier
You don't need a separate header, you can just do #include "foo.moc" at the
end.

I'd be interested in knowing in which way it is no longer c++, considering
Q_OBjECT, signals, slots, ... are just plain cpp macros (see qobjectdefs.h).

~~~
inetknght
> _I 'd be interested in knowing in which way it is no longer c++, considering
> Q_OBjECT, signals, slots, ... are just plain cpp macros (see qobjectdefs.h).
> _

It's been a while since I've used Qt but if I recall correctly MOC also parsed
and read the user interface files to generate the headers which get included
in the C++ source.

~~~
simion314
You are not forced to use the designer tool, you can build the GUI with C++
directly if you need that for some reason.

~~~
slavik81
There's also a stand-alone designer you can use on individual ui files. In
general, there's no need to have the whole project in Qt Creator just to edit
a ui file.

You can also edit the ui files in a normal text editor. They're just XML files
that specify the widget hierarchy to construct. If you have a few example
files to work from, they're pretty straight-forward to understand and modify.
Validating your changes using designer is definitely faster than recompiling
your program, but it's an option.

------
JoshTriplett
This is really impressive!

It'd be nice to have a tool that performs a one-time migration tool from Qt-
compatible sources that expect the use of moc to code that uses Verdigris,
which can then be checked into source control and maintained in place of the
original.

~~~
jcelerier
I have started such a tool in python (see the github issues) but never got
around finishing it... got me 90% of the way for a few hundred kloc codebase
though.

------
self_awareness
I think that MOC is the problem only for people that don't do much Qt
development at all.

MOC integrates into Qt build system so well that it's mostly invisible.

A bigger problem is the deployment step, at least on Linux. How to deploy Qt
apps with Qt libraries bundled with the app, so that it uses system's look and
feel is something I still don't know how to do.

~~~
weberc2
When I was doing Qt development, getting CMake to build Qt projects properly
was absurdly difficult. CMake had added some half-baked first class functions
for building Qt (it's insane that a build system has first class knowledge of
certain libraries, but insanity is par for the CMake course), but you still
had to invoke them yourself and the various docs, blog posts, stackoverflow
answers, etc gave different advice about invoking them but rarely did the
advice work (and if it did work, it never generalized to non-toy projects). My
understanding is that CMake has improved its insane first-class Qt functions
such that it's easier.

(There's also qmake, but at the time I was using Qt, it only worked if you
didn't depend on anything that wasn't also a qmake project, which is just more
C++ build system insanity).

------
ncmncm
All I can say is, About Time!

Welcome to the millennium.

