Trap candidate: resized-on-set-size
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
Research direction
First provide a public SDL3 port, commit, or issue showing this resize behavior causing a bug; the report says no real code has demonstrated it yet. If it qualifies, read “Adding a trap” in CONTRIBUTING.md and use mouse-logical-coords as the reference. Add the card to plugins/sdl3-porter/skills/sdl3-porter/references/video.md, with fixtures passing CI on Windows, Linux, and macOS against SDL 3.2.0 and 3.4.18; remove the candidate ID from the README list.
Written by the indexing model from the issue text.
Description
What changed: SDL_EVENT_WINDOW_RESIZED is now always sent, even in response to the program's own SDL_SetWindowSize(). SDL2 code that treats it as the user resizing the window now reacts to its own calls. (migration guide)
Why it's a candidate: it compiles cleanly and can be proven headless, but no port has shown it in real code yet. It becomes a trap, with fixtures and an eval case, when a port or an issue shows it. If your SDL3 port ran into it, comment with the code.
Taking it on: first comment with the real code that shows it: a public SDL3 port, commit or issue where it caused a bug. Once I confirm it qualifies, follow "Adding a trap" in CONTRIBUTING.md and copy mouse-logical-coords for the window and the event loop. The card goes in plugins/sdl3-porter/skills/sdl3-porter/references/video.md. The fixtures have to pass CI on Windows, Linux and macOS against SDL 3.2.0 and 3.4.18, and the PR removes the id from the README's list of candidates. I run the eval case myself, because evals use a repository secret.
- Dominant language
- C
- Stars
- 1
- Forks
- 1
- Avg merge
- 3m
- Merged PRs (30d)
- 1
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from hazeliscoding/sdl3-porter
-
trap-cards check: require every part of a trap cardPossibly taken A pull request linked to this issue is open or already merged. Openenhancement good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
hazeliscoding/sdl3-porter#20 ·
-
documentation good first issue
Difficulty 1/5 1-3 hours Newbie friendliness 83/100
hazeliscoding/sdl3-porter#19 ·
-
Test find_traps.py's search of the committed SDL2 codePossibly taken @ian0318git claimed this 1 day ago. Opengood first issue
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
hazeliscoding/sdl3-porter#18 ·
-
bug good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 90/100
hazeliscoding/sdl3-porter#17 ·
-
trap-cards check: require a sample and an eval case for every trapPossibly taken A pull request linked to this issue is open or already merged. Openenhancement good first issue
Difficulty 3/5 1-2 days Newbie friendliness 82/100
hazeliscoding/sdl3-porter#21 ·
All issues in hazeliscoding/sdl3-porter
Similar issues
-
TLS: a stale OpenSSL error makes non-blocking reads fail with "Resource temporarily unavailable"Open
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
Difficulty 1/5 1-3 hours Newbie friendliness 82/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
bigtreetech/BIGTREETECH-TouchScreenFirmware#3056 ·
Maintainers usually reply within 1 day
-
Allow pillow 13Open
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
[pico][astrocade] emu/apply.sh edits src/mame/midway/astrohome.cpp, which current MAME has in bally/Open
Difficulty 2/5 1-3 hours Newbie friendliness 83/100
FujiNetWIFI/fujinet-firmware#2120 ·
Maintainers usually reply within 1 day