Tkinter: The good, the bad, and the ugly!

[Adam Skutt]

On Jan 18, 6:36 pm, rantingrick <rantingr... at gmail.com> wrote:
On Jan 18, 4:57 pm, Adam Skutt <ask... at gmail.com> wrote:
> On Jan 18, 4:45 pm, Arndt Roger Schneider <arndt.ro... at addcom.de>
> > > E.g. a button is:
> > > A function gets asychnronously performed in response to
> > > a finger/mouse click and release inside a certain screen area.
> > No, that is not the definition of a 'button', not even when we choose
> > to ignore how it is rendered, which you cannot ignore even if you wish
> > to pretend you can.  Otherwise, I could always treat hyperlinks and
> > buttons as equivalent and even interchangeable.  Unfortunately, they
> > are no such things.


> What! YES it is Adam! And you just exposed yourself as an
> argumentative moron!
>
> A hyperlink and a button are EXACTLY the same thing "functionality"
> wise.

:active, :visited:, :hover, and the concept of "onhover" all would
like to have a word with you.  They have different presentation which
yields to different functionality: if it's important to tell a user
"Hey, you've been there before", then a button is entirely unsuitable,
while a hyperlink is designed precisely for that situation.
Hyperlinks change their presentation to indicate mouse focus
(nevermind the mouse cursor itself normally), buttons don't
necessarily do either[1].  Hyperlinks can certainly decay to become
button-like, but buttons cannot do everything hyperlinks can do.

Checkboxes and radio buttons are a much better rebuttal, as they
usually present "almost" the same API and expect the same model on
part of the application programmer.  It's the "almost" that kills us:
radio buttons only behave in the desired way when part of a button
group, forcing us to be cognizant of the fact we're creating radio
buttons (since we must create button groups as well).  Checkboxes
support tri-state functionality, and sometimes radiobuttons do as
well.  Pushbuttons do no such thing[2].

It'd be nice to be able to support the abstract notion of a "button"
and get what I wanted, but that requires guessing at intent and
computers are notoriously lousy at that.

> The fact that they look different has nothing to do with the
> argument.

Actually it does, but they not only look different, they /behave/
differently.  Both in terms of how a user interacts with them, and in
terms of how we interact with them in code.

> More argumentative crap. Adam you are incapable of compromise or
> reason... or maybe both. Try more facts next time.

I'm not the one suggesting that the only difference between a
hyperlink and a button is how they are rendered, FFS man, have you
ever even used a modern GUI?  Are you posting from tin?

Adam

[1] Even when they do, it's not intended to be controlled by the
application.  Native button widgets have no real built-in support for
user-controlled styling on mouse focus, you'd have to do the drawing
yourself (at which point you might as well write a custom widget).
[2] I'm ignoring the UI problems with radio buttons and checkboxes, of
course.  Point is, even among things where the differences are subtle,
the differences have inescapable ramifications on the code I write.