Tk Source Code

==== 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.

Fix merged to trunk and core-8-6-branch.

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].

About computing he expected size with font measure and font metrics:

Regarding width, as a starting point, I came up with the following:

<verbatim>
    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}]
</verbatim>

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.

Your changes look reasonable. Using the verified font is the right approach (but so also would be computing the expected size with <code>font measure</code> and <code>font metrics</code>, though that's technically testing something slightly different).

Fix proposed in branch bug-2cf3d6942c