Several test_ttk and test_tkinter GUI tests probe widget elements at fixed pixel coordinates (typically (5, 5)) or scan a fixed pixel range (e.g. 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.
This produces two failure modes:
- The test fails outright at high DPI (e.g.
NotebookTest.test_traversal clicked (5, 5), which no longer lands on a tab at scaling 2.0).
- The test passes by accident — its assertion accepts
'' (the "nothing here" result), so it never actually exercises the behaviour it claims to (e.g. ScaleTest.test_identify always identified '' at (5, 5); the darwin branch of test_traversal asserted identify(5, 5) == '').
Both are latent: they surface on Retina/HiDPI macOS (Homebrew Tk 9, scaling 2.0) and any X11 display with a high -dpi.
Fix: compute probe coordinates from the widget's own realized geometry instead of hardcoding pixels — ttk::notebook index @x,y for a point guaranteed to lie on a given tab, winfo_width()/winfo_height() centre for Entry, Scale.coords() for the trough, and scanning the real winfo_height() for Treeview rows. This makes the tests position-, theme-, platform- and scaling-agnostic, and removes the darwin coordinate special-cases.
Test-only change. Affects test_ttk (EntryTest.test_identify, NotebookTest.test_tab_identifiers, NotebookTest.test_traversal, TreeviewTest.test_tag_bind) and test_tkinter (ScaleTest.test_identify). Verified across scaling 1–6 (DPI 72–432) on Tk 8.6.17 and 9.0.3.
Linked PRs
Several
test_ttkandtest_tkinterGUI tests probe widget elements at fixed pixel coordinates (typically(5, 5)) or scan a fixed pixel range (e.g.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.This produces two failure modes:
NotebookTest.test_traversalclicked(5, 5), which no longer lands on a tab at scaling 2.0).''(the "nothing here" result), so it never actually exercises the behaviour it claims to (e.g.ScaleTest.test_identifyalways identified''at(5, 5); the darwin branch oftest_traversalassertedidentify(5, 5) == '').Both are latent: they surface on Retina/HiDPI macOS (Homebrew Tk 9, scaling 2.0) and any X11 display with a high
-dpi.Fix: compute probe coordinates from the widget's own realized geometry instead of hardcoding pixels —
ttk::notebook index @x,yfor a point guaranteed to lie on a given tab,winfo_width()/winfo_height()centre for Entry,Scale.coords()for the trough, and scanning the realwinfo_height()for Treeview rows. This makes the tests position-, theme-, platform- and scaling-agnostic, and removes the darwin coordinate special-cases.Test-only change. Affects
test_ttk(EntryTest.test_identify,NotebookTest.test_tab_identifiers,NotebookTest.test_traversal,TreeviewTest.test_tag_bind) andtest_tkinter(ScaleTest.test_identify). Verified across scaling 1–6 (DPI 72–432) on Tk 8.6.17 and 9.0.3.Linked PRs