:-| But why are the new ttk::checkbutton not tristate? (JH: it is, from the docs: The widget sets the alternate state whenever the linked -variable is unset. (The alternate state may be used to indicate a tri-state or indeterminate selection.))
HE Sorry! The ttk::checkbutton docu says: to indicate a tri-state or indeterminate selection.
This means. The programmer can find out if the ttk::checkbox is in tristate.
But there is no simple way to set the ttk::checkbutton in a state, to show the user the tristate.
The normal checkbutton have a -tristatevalue. If the variable named by -variable is set to the
-tristatevalue, the user see a checked box with gray background (default on w32).
: Perhaps this behavior can be simulate with ttk::checkbutton. But it's not in the docu. And I don't know how? So from my point of view
ttk::checkbutton are not tristate (or better ttk::checkbutton don't show tristate)
checkbutton .c1 -variable c1 -onvalue a -offvalue b -tristatevalue c
checkbutton .c2 -variable c2 -onvalue a -offvalue b
pack .c1 .ce -side left
set c1 a ;# .c1 checked (on)
set c1 b ;# .c1 unchecked (off)
set c2 b ;# .c2 unchecked (off)
;# .c2 checked with grey background (tristate) ?
:-) lassign: I like the foreach-term but lassign looks faster:
time {foreach {a b c} [list de da lus] {break}} 1000
2.396 microseconds per iteration
time {lassign [list de da lus] a b c} 1000
1.632 microseconds per iteration
DKF: note that that's not a fair test of foreach; put each in a procedure or lambda term to test properly
HE I don't think the test is unfair. Both are one command, three variables, one list to generate with the same values, must be interpreted.
But for your reassurance:
proc a {} {
foreach {a b c} [list de da lus] {break}
return
}
proc b {} {
lassign [list de da lus] a b c
return
}
time {a} 1000
1.643 microseconds per iteration
time {b} 1000
1.234 microseconds per iteration
a. 1.643 / 2.396 => 68,6% time saved after bytecoded
b. 1.234 / 1.632 => 75,6% time saved after bytecoded
=> bytecoding saves ~70% time
=> lassign still looks faster
Is this what you mean?
DKF: Yes. Wow; while I wrote that code, I didn't expect a speedup in this situation as lassign is implemented as a whole load of bytecodes and foreach has specialist ones. Might be worth rethinking the foreach compiler...
:-( text widget: What's that. Font has changed to a fixfont. And from a normal font to a named font (returnvalue from [.t configure -font] changed). First breaks the look and feel in some of my scripts and last breaks compatibility. I had to change my scripts.
:-( ttk::notebook: tabs changes their size and becomes unreadable when windows size shrink. I expected arrowbuttons like the BWidgets notebook. Or, as an alternative, breaking tabs in additional rows. The bwidget way works better on small displays like pocketPC.
:-) ttk::combobox: Works fine. Easy to replace the BWidget ComboBox.