Age | Commit message (Collapse) | Author |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Reported to me by John Chew, if you…
* Made a vertical play
* …through an existing tile
* …which makes horizontal words below the existing tile
* …and one of the horizontal words is phony
Then the phony is not detected. The logic for horizontal
plays was correct…an easy-to-overlook mistake existed in
the parallel logic for vertical plays.
|
|
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.
|
|
|
|
|
|
|
|
Dropping any info about building with qmake. Once I’ve
verified that all of the individual pieces build with cmake,
I’ll remove the .pro files, too.
|
|
Looks like Qt6 dropped support for Windows-x86.
|
|
This will hopefully fix the GitHub actions build.
Definitely fixes my local build. This won’t stand
for a deployment to users, but it works for developing.
|
|
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.
|
|
|
|
And it wasn't needed anyway, so remove it from both Qt5 and Qt6 builds.
|
|
* Remove all uses of `using namespace std` from header files (although a
few specific cases of things like `using std::vector` remain)
* Move all existing uses of `using namespace std` in cpp files to after the
header includes
* Make coordinating changes so it builds again.
Qt6 builds on Windows were breaking because of namespace collision between
std::byte and some version of `byte` in one of Qt's namespaces. That breakage
is now fixed.
It would be good to systematically clean up all `using` declarations in header
files to ensure nothing is leaking out, but that's for another time.
|
|
C++17 is a requirement for Qt6. It’s been out long enough that
I think we’re safe just requiring it globally.
|
|
The cmake file now takes a QT_VERSION string setting. The first
character of the string is “6”, then cmake calls find_package
on Qt6…otherwise, it calls find_package on Qt5.
Qt 6.5.2 builds added to the GitHub Actions build matrix.
|
|
|
|
|
|
QTextStream::setCodec() is no longer a thing in Qt6. Most of
our call are to set the codec to UTF-8, which happens to be the
default encoding in Qt6. So make a macro so this can compile
in both Qt5 and Qt6.
|
|
I think these changes would still be fine in Qt5, but
are required for Qt6.
Also DataLocation was deprecated in v6, AppLocalDataLocation
is the same for both Qt5 and Qt6.
|
|
|
|
Some of the signals we’re using aren’t supported or working
in Qt 6. Refactor for things that are working and
documented.
|
|
|
|
* Remove deprecated Ubuntu, add new Ubuntu
* Fix usage of action/cache
* Remove Appveyor
* Update .gitignore for clangd cache
|
|
|
|
|
|
Travis has been throwing a lot of false failures on the Mac build, which was
always super-slow anyway. And now it's been suggested that Travis ain't gonna
last in the open-source-free-for-use CI business. So out it goes.
In its place, GitHub Actions. Just one for now, which runs the build on
pushes to master and on PRs (I hope...haven't tested the PR bit yet).
Notes about the new system...
* It uses the cmake build. Next step...document the cmake system and
de-document the qmake system.
* It tests against both Qt 5.12.0 and 5.15.1.
* Mac, Windows (x64, x86) and Linux (Ubuntu 18.04, 20.04)
* On Linux, it also builds clang and g++.
* In all of the above cases, it's just pretty much default compilers. Which
is probably good...particularly on Linux, where it's not so common for
non-developers to be running major compiler updates.
* All cmake builds use ninja and cache their Qt downloads, so the result is
fairly fast.
* No builds of makegaddag, gaddagize, makeminidawg, iotest, or encodeleaves
yet, as I haven't migrated those to cmake. Need to get on that.
|
|
Generator::filterOutDuplicatePlays was using the Move::usedTiles()
which fails to different between uses of a blank as different letters.
|
|
|
|
|
|
|
|
|
|
|
|
* Replace std::random_shuffle() with std::shuffle().
* Populate switch statements which were checking the
Move enums, but not Move::PlaceError.
* endl -> Qt::endl for QTextStream usage.
* QString::SkipEmptyParts -> Qt::SkipEmptyParts
* QLabel::pixmap() now takes Qt::ReturnByValue
* Use QElapsedTimer where appropriate.
|
|
Apparently, when you serialize a pixmap through a QDataStream(), it loses
track of its devicePixelRatio setting. End rule was that if, on a HiDpi
screen, you dragged and dropped a tile within the rack, you'd get a tile that
was larger than it should have been by a factor of the default pixel ratio.
Solution is to simply reapply the pixel ratio to the newly created Pixmap
after deserializing it in the drag-drop code.
|
|
If a play was made from tiles not on the rack, it brings up the
"Verify Play" dialog, to which one of the options is to cancel the
play. But canceling the play didn't work. Now it does.
|
|
|
|
|
|
|
|
|