Ticket UUID: | 2cf3d6942c75aca1a90e32bbf7fbe8a7f06ac43d | |||
Title: | Test button-5.24 ConfigureButton - computing geometry fails on Linux | |||
Type: | Bug | Version: | core-8-6-branch | |
Submitter: | fvogel | Created on: | 2016-08-19 21:37:41 | |
Subsystem: | 03. [*button] and [label] | Assigned To: | fvogel | |
Priority: | 6 | Severity: | Minor | |
Status: | Closed | Last Modified: | 2016-08-29 18:04:29 | |
Resolution: | Fixed | Closed By: | fvogel | |
Closed on: | 2016-08-29 18:04:29 | |||
Description: |
==== button-5.24 ConfigureButton - computing geometry FAILED ==== Contents of test case: button .b -borderwidth 2 -highlightthickness 2 -font {Helvetica -12 bold} .b configure -text "Sample text" -width 10 -height 2 pack .b set result "[winfo reqwidth .b] [winfo reqheight .b]" .b configure -bitmap questhead lappend result [winfo reqwidth .b] [winfo reqheight .b] ---- Result was: 102 46 20 12 ---- Result should have been (exact matching): 104 46 20 12 ==== button-5.24 FAILED Linux Debian 8 with core-8-6-branch. Always repeatable. | |||
User Comments: |
fvogel added on 2016-08-29 18:04:29:
Fix merged to trunk and core-8-6-branch. fvogel added on 2016-08-23 18:30:54: Thinking further: Problem 1 can be easily overcome by setting -padx and -pady to a value in pixels. Problem 2 is not a problem: the off-by-2 is intentional in tkUnixButton.c --> just add this to the expected size result. I have now made a hopefully better test that solves the above and computes the expected sizes of the button in the two cases tested by button-5.24 (i.e. purely text button, and purely image button). See [a6f3ed76]. fvogel added on 2016-08-20 20:31:53: About computing he expected size with font measure and font metrics: Regarding width, as a starting point, I came up with the following: set textwidth [font measure [.b cget -font] -displayof .b [.b cget -text]] set paddingXpixels [expr {3 * [winfo screenwidth .b]/[winfo screenmmwidth .b]}] set expectedwidth [expr {$textwidth + 2*[.b cget -borderwidth] + 2*[.b cget -highlightthickness] + 2*$paddingXpixels}] There are 2 problems with this: 1. The hardcoded 3 in the calculation of paddingXpixels is because [.b cget -padx] returns "3m" for me, i.e. a distance on screen in millimeters. Is it always the case, or should the test consider all the possibilities of Tk_GetPixels (i.e. pixels, centimeters, millimeters, inches, and printer's points) ? This would become rather convoluted... 2. The calculation above is still off by 2 compared to the size computed by Tk. Why? All in all, considering that the test is constrainted by 'font', I think the hardcoded widths and heights of the button are good enough for the test purpose. dkf added on 2016-08-20 15:20:07:
Your changes look reasonable. Using the verified font is the right approach (but so also would be computing the expected size with fvogel added on 2016-08-19 21:43:28: Fix proposed in branch bug-2cf3d6942c |