Skip to content

gh-153716: Harden ttk/tkinter GUI tests against display scaling#153717

Open
serhiy-storchaka wants to merge 2 commits into
python:mainfrom
serhiy-storchaka:gh-153716-harden-gui-tests-dpi
Open

gh-153716: Harden ttk/tkinter GUI tests against display scaling#153717
serhiy-storchaka wants to merge 2 commits into
python:mainfrom
serhiy-storchaka:gh-153716-harden-gui-tests-dpi

Conversation

@serhiy-storchaka

@serhiy-storchaka serhiy-storchaka commented Jul 14, 2026

Copy link
Copy Markdown
Member

Several test_ttk and test_tkinter GUI tests probed widget elements at fixed pixel coordinates (typically (5, 5)) or scanned a fixed pixel range (range(5, 100, 5), range(0, 100, 10)). ttk element geometry — tab padding, the focus ring, trough insets, row height — scales with the display DPI (tk scaling), so a fixed pixel that lands on the intended element at a normal scaling lands on a different element, or misses it entirely, at a high DPI. The test then either fails outright or passes by accident, its assertion accepting '' (the "nothing here" result) so it never actually exercises the behaviour it claims to.

This surfaces on Retina/HiDPI macOS (Homebrew Tk 9, scaling 2.0) and on any X11 display with a high -dpi.

The probe coordinates are now computed from each widget's own realized geometry instead of being hardcoded:

  • NotebookTest._tab_point() — a new helper returning a point that really lies on a given tab, via the ttk::notebook index @x,y subcommand. Used by test_traversal (which now also asserts the selection before and after the click) and test_tab_identifiers.
  • EntryTest.test_identify — probes the widget centre (winfo_width()/winfo_height()).
  • TreeviewTest.test_tag_bind — scans the real winfo_height() for item rows.
  • ScaleTest.test_identify — probes the trough centreline from Scale.coords().

This makes the tests position-, theme-, platform- and scaling-agnostic and removes the darwin coordinate special-cases.

Test-only change. Verified across scaling 1–6 (DPI 72–432) on Tk 8.6.17 and 9.0.3.

🤖 Generated with Claude Code

Compute probe coordinates from the widget's own realized geometry
instead of hardcoding pixels such as (5, 5), which land on a different
element, or miss it entirely, at a high display scaling.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
…ixed pixel

The arrow-click test helpers probed a fixed x = width - 5, which at a
high display scaling on Tk 9.1 lands in the arrow element's right-hand
border (the border scales with the DPI), so identify() there returns
'field' and the test fails.  Scan inward from the right edge for the
arrow element instead.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

awaiting core review tests Tests in the Lib/test dir

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant