Tk Source Code

Tk 8.6 got this right...

% package require Tk
8.6.18
% [button .b] configure -padx "3 m"
% llength [.b cget -padx]
2

Tk 9 gets it wrong:

% package require Tk
9.0.3
% [button .b] configure -padx "3 m"
% llength [.b cget -padx]
1

Simple fix [526669416126d796|here]

Ping

At least on Linux, the Tk test suite does not have
any tests of pixel or mm values that have whitespace
between the number and the units designation.

The "mm" Tcl_ObjType suffers from the same bug.

The "pixel" and "mm" types are 95%+ identical.
Is there truly a need for both of them?  Even
if there is, couldn't they be refactored to share
a large fraction of their implementation?

A corner case to consider:

% [button .b] configure -padx "0x10 c"
% .b cget -padx
0x10 c

The simplest fix is to revert the adoption of the extended
Tcl_ObjType functionality.

An alternative would be to revise the "lengthProc" in the
pixel Tcl_ObjType to report the correct length, taking the
steps to distinguish the length 1 values from the length 2 values.

A mildly incompatible alternative would be to revise
the SetPixelFromAny() function so that values with whitespace
between the number and the units are rejected, so that length 2
list values are no longer accepted as pixel values.

The choice between these options (or another one) would be better
made by Tk developers who can anticipate the effect on other
parts of the Tk code base, and the world of Tk code out there.

In Tk 9, the "pixel" Tcl_ObjType is using the abstract list features
of Tcl_ObjType to report that when used as a list, every pixel value
is a list of length 1, which the demo script shows to be false.