Fix tests and some of the code to work with Anki 2.1.50

[oakkitten]

In addition to the tests environments added in #306, this adds two environments for Anki 2.1.50, to test with Qt5 and Qt6. Also, I fixed the way buttons look in the Edit dialog on 2.1.50 and added some tests for the buttons themselves. Also included is a fix for #308.

Essentially, this makes the tests pass, and I can add and view cards via Yomichan on Windows without issues now. There might still be some issues in the untested areas maybe.

This draft is based on the current master, which includes the squashed #306. I would be more than happy to rebase it on the original, unsquashed commits of #306. These were good commits, or so I want to believe 😔. (They say that you should never rewrite master, but I won't tell anyone if you don't.)

This PR is mostly OK but I'll give it a few days before marking as ready—just in case.

[FooSoft]

Looking forward to it! I greatly appreciate the TLC you are doing here.

The reason that I squash by default is that a PR is considered to be a logical unit of work. If we have some sort of unexpected, non-trivial break, the first thing that will happen is that the entire feature work (PR) will get reverted to get back to a working state. This is simply more difficult to do when there are many individual commits, you might miss some, etc.

It gets even crazier if there are interleaved commits with that of other people! AnkiConnect is a "community" project, and has a very large number of contributors. It can get difficult to keep track of things even when only doing one PR at a time.

That being said, you are absolutely welcome to smaller "units of work" and PR those.

[oakkitten]

This is simply more difficult to do when there are many individual commits, you might miss some, etc.

Actually, you can eat the cake and have it, too!

GitHub will create a merge commit if you don't squash. That's like merging with the --no-ff flag. So while GitHub itself will only show one branch, the actual git graph will look like this:

* e813b965 Merge pull request 420
|\
| * 2f9e89b3 Commit 2
| * f6d3dabc Commit 1
|/
* ...

This way, you can revert any of the individual commits, or the entire PR by reverting the merge commit.

While having non-linear bits in history can be a bit confusing, being able to tell why some contributor added this or that piece of code, and being able to make use of git blame is, I think, invaluable. And using an editor such as PyCharm you can easily tweak filter the graph to make it show a slice of commits in a way that is easy to understand.

P.S. what's TLC? :3

[FooSoft]

Good call, best of both worlds indeed. I don't actually mind doing history rewrite, but not sure if GitHub will let that happen with a PR. If you have a good idea how to make that happen, I'm all ears :)

TLC = tender love and care!
Something this project needs a lot of.

[oakkitten]

Aw. I do love Anki-Connect indeed 💖

I guess GitHub won't allow un-doing a squash from the web interface, but you can always merge a branch via git. If you do want to go through with it, I suppose you:

• git reset master to whatever commit was there before the PR's squashed commit;
• Fetch the edit-dialog branch. There are a few ways to do this;
• See that I didn't screw with the branch by verifying that the latest commit hash in that branch is the same as in the PR 😛
• From master, merge it without fast-forwarding by saying something like git merge --no-ff oakkitten-edit-dialog. Instead of “Merge pull request...” the commit message will say “Merge branch...” by default, but it amounts to the same thing and you can change it however you like, too;
• Verify that git log --graph does have the branch and the merge commit;
• Verify everything yet again and finally do the dreaded git push --force.

[FooSoft]

@oakkitten done, feel free to send newly rebased PR when you're ready

[oakkitten]

Okay, great! This PR should be good. Seeing that 2.1.51 is out now, I'll just see if all works with that as well.

(I'm not entirely sure if it's worth testing against every Anki version. 2.1.49 was stable but 2.1.50 apparently isn't, and 2.1.52 is already in the works... Who knows if it well be stable? Well, I guess this won't hurt, at least if we don't have to write too many hotfixes for the unstable versions?)

[cjdduarte]

Okay, great! This PR should be good. Seeing that 2.1.51 is out now, I'll just see if all works with that as well.

(I'm not entirely sure if it's worth testing against every Anki version. 2.1.49 was stable but 2.1.50 apparently isn't, and 2.1.52 is already in the works... Who knows if it well be stable? Well, I guess this won't hurt, at least if we don't have to write too many hotfixes for the unstable versions?)

ANki connect didn't work on Anki 2.1.50, but it worked on Anki 2.1.51 even without this fix.

[oakkitten]

Yes, it mostly did (the method guiAddCards was the only broken one), unless you turn off Qt6 compatibility shims. These are turned on by default and likely to stay that way for a while, but it's nice knowing that we can work without them. This also fixed the tests.