Button size weirdness
in [TCL]
|
From: Erik Leunissen on 9 Feb 2010 16:35 Ralf Fassel wrote: > * Erik Leunissen <look(a)the.footer.invalid> > | % pack [button .b -width 20 -height 20 -image img -bd 0 > | -highlightthickness 0 -padx 0 -pady 0] > | % update idletasks ;# probably only necessary if executed non-interactively > | % winfo width .b > | 22 > | % winfo height .b > | 22 > | > | Any ideas ? > > unix/tkUnixButton.c has this code at the end of TkpComputeButtonGeometry(): > > if ((butPtr->type == TYPE_BUTTON) && !Tk_StrictMotif(butPtr->tkwin)) { > width += 2; > height += 2; > } > > Indeed, if I set tk_strictMotif, I get the specified width/height: > > % set tk_strictMotif 1 > 1 > % image create photo img > img > % pack [button .b -width 20 -height 20 -image img -bd 0 -highlightthickness 0 -padx 0 -pady 0] > % winfo width .b > 20 > % winfo height .b > 20 > > % destroy .b > % set tk_strictMotif 0 > 0 > % pack [button .b -width 20 -height 20 -image img -bd 0 -highlightthickness 0 -padx 0 -pady 0] > % winfo width .b > 22 > % winfo height .b > 22 > > HTH Sure it helps! This seems to lead to something conclusive. (need to read up on tk_strictMotif ... ) Thanks for diving into these depths! Erik. > R' -- leunissen@ nl | Merge the left part of these two lines into one, e. hccnet. | respecting a character's position in a line.
From: Erik Leunissen on 9 Feb 2010 16:54 Ralf Fassel wrote: > > unix/tkUnixButton.c has this code at the end of TkpComputeButtonGeometry(): > > if ((butPtr->type == TYPE_BUTTON) && !Tk_StrictMotif(butPtr->tkwin)) { > width += 2; > height += 2; > } > > Indeed, if I set tk_strictMotif, I get the specified width/height: > > % set tk_strictMotif 1 > 1 > % image create photo img > img > % pack [button .b -width 20 -height 20 -image img -bd 0 -highlightthickness 0 -padx 0 -pady 0] > % winfo width .b > 20 > % winfo height .b > 20 > > % destroy .b > % set tk_strictMotif 0 > 0 > % pack [button .b -width 20 -height 20 -image img -bd 0 -highlightthickness 0 -padx 0 -pady 0] > % winfo width .b > 22 > % winfo height .b > 22 > OK. Do you agree with my conclusion that the observed behaviour is: a failure of [winfo width] and [winfo height] to account for button pixels (in a case that is very common: tk_strictMotif = 0). Erik. > HTH > R' -- leunissen@ nl | Merge the left part of these two lines into one, e. hccnet. | respecting a character's position in a line.
From: tom.rmadilo on 9 Feb 2010 18:10 On Feb 9, 1:54 pm, Erik Leunissen <l...(a)the.footer.invalid> wrote: > Ralf Fassel wrote: > > > unix/tkUnixButton.c has this code at the end of TkpComputeButtonGeometry(): > > > if ((butPtr->type == TYPE_BUTTON) && !Tk_StrictMotif(butPtr->tkwin)) { > > width += 2; > > height += 2; > > } > > > Indeed, if I set tk_strictMotif, I get the specified width/height: > > > % set tk_strictMotif 1 > > 1 > > % image create photo img > > img > > % pack [button .b -width 20 -height 20 -image img -bd 0 -highlightthickness 0 -padx 0 -pady 0] > > % winfo width .b > > 20 > > % winfo height .b > > 20 > > > % destroy .b > > % set tk_strictMotif 0 > > 0 > > % pack [button .b -width 20 -height 20 -image img -bd 0 -highlightthickness 0 -padx 0 -pady 0] > > % winfo width .b > > 22 > > % winfo height .b > > 22 > > OK. Do you agree with my conclusion that the observed behaviour is: > > a failure of [winfo width] and [winfo height] to account for button > pixels (in a case that is very common: tk_strictMotif = 0). You really should bring this up with the authors of the code. I'm somewhat confused myself. Calculating the window size should not depend on logic, just simple arithmetic, or even introspection. IMHO, what is needed is a pixel level tutorial to tk widgets. Maybe that is impossible, but I can't imagine HTML ever surviving without such control.
From: Koen Danckaert on 10 Feb 2010 04:39 > Ralf Fassel wrote: >> unix/tkUnixButton.c has this code at the end of TkpComputeButtonGeometry(): >> >> if ((butPtr->type == TYPE_BUTTON) && !Tk_StrictMotif(butPtr->tkwin)) { >> width += 2; >> height += 2; >> } >> And just above that code, there's the following comment: /* * When issuing the geometry request, add extra space for the indicator, * if any, and for the border and padding, plus two extra pixels so the * display can be offset by 1 pixel in either direction for the raised or * lowered effect. */ Erik Leunissen wrote: > OK. Do you agree with my conclusion that the observed behaviour is: > > a failure of [winfo width] and [winfo height] to account for button > pixels (in a case that is very common: tk_strictMotif = 0). Why call it a failure? It's just intended behaviour, accoring to the code. --Koen
From: Erik Leunissen on 10 Feb 2010 05:59
Koen Danckaert wrote: >> OK. Do you agree with my conclusion that the observed behaviour is: >> >> a failure of [winfo width] and [winfo height] to account for button >> pixels (in a case that is very common: tk_strictMotif = 0). > > Why call it a failure? It's just intended behaviour, accoring to the code. Intended behaviour of the [button] command (under unix), sure! Intended behaviour of [winfo width] and [winfo height], no! Erik. > > --Koen -- leunissen@ nl | Merge the left part of these two lines into one, e. hccnet. | respecting a character's position in a line. |