The great purge
Git is my VCS-system of choice and github most of the time the place for my publicly shared repositories.
Over the years some clutter piled up there:
- unfinished business; projects which were started (with best intentions) and never finished
- forked repositories, which I don’t need anymore (not sure if I will remove also those were I contributed, because then the evidence is more or less gone, or?)
- code I am a bit ashamed right now :’) (if you have no projects were you laugh heartily about how naively you implemented them at that time, then you made no progress)
Therefore I started to check them to see if it makes sense to keep or delete them. Right now I am down to 39 and the delete-button is still hot 😉
Find crappy Qt-includes
Use this regular expression
|
1 |
[\/][q]\w+[\.][h][>] |
to check for includes of the format
|
1 2 3 |
#include <QtCore/qdir.h> // hit #include <QtCore/QDir> // no hit #include <QtCore/QDir.h> // no hit |
Test it here with regex101.com.
QDialogs receive NO close-event in case of closing via the ESC-key. Nice.
At first this looked like a bug, but upon reading carefully the documentation and crawling the internet, I’ve noticed that this is
a) wanted behavior and b) I am not the first one stumbling over this issue.
So just override in the header the method for processing the QHideEvent:
|
1 2 3 4 |
protected: // Closing a QDialog via key 'ESC' does NOT result in a close-event. // Therefore we capture the QHideEvent <3 void hideEvent(QHideEvent* eventHorizon) override; |
And reimplement the base-class-call with the emission of a custom signal (or triggering custom functionality) for futher processing. Like:
|
1 2 3 4 5 6 |
void MyDialog::hideEvent(QHideEvent* eventHorizon) { // emit signalDialogClosed(); QDialog::hideEvent(eventHorizon); } |
Edit:
Another way is to connect the QDialog’s finished-signal to your signal via DirectConnection. Less code than overriding.
qobjectdefs_impl.h:72:118: error: no type named ‘Car’ in ‘struct QtPrivate::List<>‘
Bruh, wait, what?
After rebasing a bigger feature and solving all obvious conflicts, the new build threw an error like “no type names Car”. And I am currently not working in the automotive industry!
Issue was that a commit, on which was rebased, changed ‘old’ Qt4-signal-slot-syntax (with SIGNAL/SLOT keywords; the string-based connect) to the ‘new’ Qt5-version (typed and verifyable from the compiler). And one of the slots had a default parameter. This is not allowed, except you squish a lambda as intermediate layer.
|
1 2 3 4 5 6 7 8 |
// old version // connect( _model.get(), &AnalysisModel::signalImageChanged, // this, &ImageScene::slotImageChanged ); // ImageScene::slotImageChanged's second parameter has a default value. // Using Qt5-connects does just work with an intermediate lambda. connect( _model.get(), &AnalysisModel::signalImageChanged, this, [=](ImagePoolItem item){ ImageScene::slotImageChanged(item); } ); |
A bit more insight: Qt-docs.
edit: One of the earlier error-messags also hinted out what could be the culprit, but “no type named Car” is more funny 😉
|
1 |
qobject.h:239:9: error: static assertion failed: The slot requires more arguments than the signal provides. |