Re: ttk::checkbutton - I think, it's a bug

Bryan Oakley <oakley@xxxxxxxxxxxxxxxxxxxx> writes:

Óscar Fuentes wrote:

The bindings are (part of) the Model, and I've expressed this several

Ok, that explains a lot of why we disagree.

Sorry, my mistake, the bindings are part of the Controller. It seems
that I devote too much time to Usenet. :-)

I see the bindings as part
of the controller. And even though you've expressed your opposing
view, I somehow never got the message you thought bindings were part
of the model.

No wonder. :-)


But the checkbutton does *not* change the model. It is the bindings on
the checkbutton that change the model. This is simple to prove. Remove
all the bindings on the checkbutton and you'll see that you can click
on it all day long and your model won't change.

I'm not sure what this means. Are you saying that the checkbutton is
effetively disabled by removing all of its bindings? Or that the
checkbutton switches its "seledted" state but does not modify the


But my gripe comes from the fact that [checkbutton] *forces* you to fake
the scenario you guys are describing: a mini-semi-MVC consisting of a
variable and a checkbutton, that is a part of the bigger, "serious" MVC

Funny, when I use -variable I don't feel like I'm being forced to do

What I'm trying to say is that [checkbutton] and other widgets does not
support the approach of having all widget-related state encapsulated on
the widget itself. The people like me, who think that -variable is not
right, have no other option (no pun intented) than to use it.

Brian, do you really think on terms of MVC when you put a [checkbutton]
on some toplevel?

Yes, quite often I do think in terms of MVC when designing a GUI. I
already have my model, typically in the form of an array that has the
yes/no answer set to the default or existing value or whatnot. Then I
create the view into that data, and it's extremely convenient to
connect the two with the -variable option.

For me, the data already exists before I create the widget. I never
have to "make-up a variable for holding the value". That variable
already exists, I'm just creating a view into that variable. This is
business as usual for me.

Fair enough, but then your Models are simpler than mine, as in my GUIs
usually have a large percentage of data-entry widgets that have no
direct representation on the Model. And this without talking about non
data-entry widgets, such as action-triggerers (buttons, menus, etc) and
displays (labels, pictures, etc).


I fail to see this evidence. If it is so good, why other frameworks does
not implement it? Why is it not extended to all Tk widgets?

Maybe it's because other frameworks aren't as smart as Tk in some
regards. Not that Tk is the pinacle of design, but it was designed to
be very easy to use which sometimes results in clever ideas that more
rigid frameworks couldn't attempt. Tk and Tcl are different than
almost every other language, so it stands to reason it sometimes does
things in a way that is foreign to these other languages.

Tcl has quite a few points in common with Lisp. One of them is the
expressiveness due to the simple syntax. This is an sketch of the Lisp
Way, translated to Tcl:

checkbutton .cb -data <something>

If <something> were a variable, things would work just like -variable:
the command automatically sets a trace on the variable, etc. If
<something> were a command, that command would be invoked every time the
widget receives some input or need to update its contents. And if -data
<something> were absent, the widget would contain and handle the data

This approach is far more powerful than -variable and it creates no more
hassle to the user. Pity that the Tk designers didn't thought about it.