Fixes shift click selection after programmatic selection in most cases, Issue #2469 #3213
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Sorry about making 2 pull requests. In hindsight I could've fixed the other one. If this is acceptable, I'd like to ask one question. I'd like to try to make an automated test for this behavior, but I'm not sure were to start looking implement it. If possible, any advice on where to look would be appreciated. |
|
Thanks for looking into this! Just one minor request: please link to the issue in the comment, to make it a little easier to find the related discussion.
Even if it's not perfect, if it's less bad than what we currently have, that's a win. |
|
Added link up top 👍 |
dae
reviewed
Jun 1, 2024
|
Thank you! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Proposed fix for issue #2469
Original thread:
https://forums.ankiweb.net/t/bug-arrow-keys-in-preview-break-shift-click-selection-in-card-browser/29282
Some things I noticed while looking into this.
Changing the selection programmatically followed by shift-click selecting is what causes the issue.
This would happen when:
</>buttons were clicked in the preview windowCtrl + NorCtrl+ Ptable shortcuts were used in the browser windowHomeorEndtable shortcuts were used in the browser windowThen..
Shift + Left Clickselecting in the table viewSome quick googling showed that this was a common issue with Qt, and I reproduced it in a small mockup program I made. I'm not sure if it is a bug with Qt itself, or if there is some better/ more proper way to select items in a TableView from code.
What I added feels like a work-around more than a proper fix, but, as far as I can tell, it fixes all the mentioned scenarios.
However, if the user holds
Shiftwhile clicking the<or>buttons in the preview window the same bug reappears. I haven't been able to figure out why this still happens.