| Age | Commit message (Collapse) | Author |
|---|
|
Qt6 complains about the versions of the static function signatures
we’re using for generating various QMessageBoxes.
Except for the “Show plaintext board” dialog, which seems to
be having some “special” issues in Qt6.
|
|
That was super painful. It seems that some of the Quackle types that
have custom operator==() give fits to the MOC compiler when those
types are used as arguments for slots and/or signals (or maybe it's
only when they're connected in a certain way...frankly, I never did
figure this out precisely to my satisfaction). The compilers provide
very little help in resolving this problem.
Once I understood the problem, VS22 was giving me just the tiniest
morsel, enough that I could hunt down the offending slot/signal
(it wasn't even giving me the name of the slot/signal...just the type
it was trying to use). I've changed all offending functions to use
const pointers to types instead of const references, and this makes
Qt happy.
I couldn't find any info on the web directly about this, but here's
the closest I did find, which suggests that this is related to
increased functionality in Qt6 regarding reflection.
https://forum.qt.io/topic/141434/
This fixes my VC++22 x86-64 build. Hopefully it fixes all of the
others, too.
|
|
Some of the signals we’re using aren’t supported or working
in Qt 6. Refactor for things that are working and
documented.
|
|
|
|
Most are Qt4-isms, except where noted.
* Replaced QFontMetrics::width with QFontMetrics::horizontalAdvance,
conditionally as the latter wasn't even introduced until Qt 5.11.
* QColor::light and dark instead of QColor::light and dark.
* QString() instead of QString::null.
* std::sort instead of qSort
* QTreeWidgetItem::setSelected instead of QTreeWidget::setItemSelected.
* QFileDialog::setOption(QFileDialog::DontConfirmOverwrite) instead
of QFileDialog::setConfirmOverwrite(false).
* QDrag::exec instead of QDrag::start.
|
|
Also, extend copyright to 2019.
|
|
When going back to edit history, typing a
phoney correctly brought up a dialog, but
indicating you wanted to cancel the phoney
play didn't stop the play from going down,
or a subsequent computer player from making
its play.
|
|
|
|
Not a very interesting commit...only changes in comments.
|
|
|
