tkinter questions: behavior of StringVar, etc

[Scott David Daniels]

Alan G Isaac wrote:
> On 3/29/2009 3:43 AM Scott David Daniels apparently wrote:
>> OK, that was plain rude.  a couple of questions is not six questions.
>> A reply telling you how to get to some of what you are looking for
>> is assistance.  If you want exact answers to an array of questions,
>> pay someone to fetch you the answers, or do your own homework.
>>
>> Clearly I am too grumpy this weekend.
> 
> Yes you are too grumpy.  It is *not* rude to point
> out that the answers are not where I was pointed.
> The available docs are much more focused on "how"
> rather than on "why".
> 
But, in your original post, here is the full beginning:
 > I'm a complete newbie to GUI.
 > I have a couple questions about tkinter.
 >
 > 1. Where is the list of changes
 >    in Python 3's tkinter?
 >
 > 2. What exactly is the role of the root object,
 >    traditionally created as ``root=tk.Tk()``?
 >    What is an example where one should create this
 >    before creating a Frame instance (which will
 >    otherwise implicitly create one as its master)?

The post contains seven numbered questions (two questions are
numbered 2), the first pair of which read like demands.  Nowhere
(except the "complete newbie" part) do you say, "I might be
misunderstanding something, but ....", nor do you ask "how can
I find out, ...."  You assume there _is_ a "list of changes."
You ask, "What exactly is the role of ...", rather than saying
something like, "I don't understand the role of ...", and continue
to ask why the code is not architected the way you first expected
it to be architected, calling those things you do not understand
"magic"  (not "magically" which would at least invoke a sense of
wonder, rather than indignation).

Now I could have rooted around and found the answers to some of your
questions, but I fully expected that your reply would then have been,
"why wasn't that in the documentation," and I was feeling like asking
you to apply for a full refund on your purchase price of your Python.

It looked to me like you had no clue and wanted to learn things your
way.  If so, fine, don't ask others for help for free.  If not, it
is _your_ responsibility to discover how answers you got were meant
to help you.  You really should read:
     http://www.catb.org/~esr/faqs/smart-questions.html

> Please show me how to use that response to get
> even one of the answers.  (Please skip #2, since I
> fear a repetition of the kind of answer in all the docs,
> which is half an answer.) Or, withdraw your claim.
> 
> Btw, I cannot find the answers in Grayson's book either.
> It's a big book though, and covers much ground, so I
> do not deny the answers might well be in there somewhere.

Mike Driscoll said, among other things, "There is tons of info on the
Python wiki:   http://wiki.python.org/moin/TkInter" and pointed you
specifically at "Lutz's 'Programming Python'".  As far as I can tell,
Grayson is not Lutz's former name :-).  People learn in very different
ways.  Some people take Grayson's book and are off and running.  Lutz
takes a different approach, the Python wiki takes another approach.
Your questions reveal no particular understanding (nor effort), so the
best replies are not to address the individual questions, but to address
how you might get a global understanding.  That is how Mike Driscoll's
answer could have helped you.

Remember Python 3.X is a rebuilt Python, so lists of changes would be 
useless -- you'd be swamped in detail.

Unfortunately, every GUI system I've seen is swamped in detail, there
are a few core things to understand, but a lot of detail gets addressed
piece by piece.  There is no accepted "theory of operation" to learn in
one or two "aha" moments.  SO, the people who learn by copy-and-tweak
are much happier working in GUI than the "from first principles" people.

> Let's try just these two:
Actually a couple? Imagine that.
> - Why does a Variable need a master?
> - If s is a StringVar instance, why is
>   str(s) its name rather than its value?

The answer to that, grasshopper, lies in the answer to the question,
"What are StringVars designed to do?"  StringVars, and IntVars, and ...
are elements to receive, hold, and propagate changes to values that
will produce effects in the programs behavior or display.  I find
IntVars easier to explain, since you get values for numbers lots of
ways.  If a slider updates an IntVar, a signal must reach anything
"interested" in the value of that IntVar.  For example, you have a
rectangle, and a display of its height, width, area, and aspect ratio.
If you change the height or the width, the area and aspect ratio need
updating (as well as the value in the height or width).  Rather than
building systems where every control maintain lists of what to notify
and how to communicate the value, things like IntVars and StringVars
work as data store and signal propagation points.  One of the Vars is
more Var than value: a place to go to look for the current value, and
a place to register for notification when changes happen.  Clearly
you cannot signal changes from a variable unless the whole event
mechanism is running.  A StringVar needs to know where to send
signals about its changes.  Thus two different StringVars containing
the same text can behave quite differently, as each may be hooked into
a different network of event propagation.

So there.

--Scott David Daniels
Scott.Daniels at Acm.Org