I have recently started converting a large project to tkinter, starting
with zero knowledge of tkinter. (You are free to think: BAD IDEA. 😁)
I am well aware that adopting a new tool always involves a learning
curve, and that one is prone to think that things are more difficult
than they are/should be, and to belly-ache about it, and that in a year
from now I'll probably wonder what I'm fussing about.
Nonetheless ISTM that there is a particular problem with tkinter:
There doesn't seem to be any decent documentation for it anywhere.
I seem to have spent al least 95% (feels more like 99%) of my time in
research, only the rest available for coding. Everything I've learned
has come from scouring the Internet for Stack Overflow pages, videos,
and other articles. And while I'm VERY grateful for these resources,
most of them cover very basic use, and if I want information on some
more obscure technical point, I can only go on looking and looking and
hope I eventually stumble upon what I'm looking for, or some acceptable
substitute.
FWIW: The tkinter error messages are sometimes helpful, sometimes not,
occasionally very helpful (as when I pass an invalid option parameter to
a function and it tells me what the valid ones are). I feel there is
plenty of room for improvement.
One example for those familiar with tkinter (I assure you there are
others) of how I struggle without adequate documentation:
I had learned very early on that tkinter provides two versions of
some classes: the original, or "tk" versions, and a later generation,
the "ttk" versions (and I have to say that that was a turn-off, as it
seemed that the learning curve has just got steeper). It was surely not
appropriate for me to delve deeply into this issue at that stage, as
there were so many other things I didn't know (like, practically
everything). I decide to go with the "tk" versions pro tem, and to
investigate the "ttk" versions later if it seemed like a good idea. One
annoyance is that some webpages are relevant to one version, some to the
other, almost always without being explicit about which. (Can't blame
the "tk" ones, as they were probably written before "ttk" was invented.)
I was writing a subclass of the Checkbutton class (tkinter's name
for what I call a checkbox). I needed to be able to (1) set (2) clear
(3) interrogate the checked state. This is easy to do if you associate
a "variable" with each Checkbutton instance, as seems to be usual
tkinter practice. ("variable" is not a variable in the usual sense, but
an object provided by tkinter that is linked to a GUI object (such as a
Checkbutton), so that when the GUI object changes, the value of the
"variable" changes, and vice versa.) However, I decided that I wanted to
dispense with the variable, if possible. (My motivation? Simpler
code. Shorter code. Avoiding using up resources by creating
unnecessary objects. You are free to think that I was misguided. You
are free to think that I should have been happy with something that
worked.) I didn't care whether I used a tk.Checkbutton or a
ttk.Checkbutton.
From various Internet articles I discovered (slowly, after wading
through many articles that DID use a "variable"):
A way of GETting the state of a tk.CheckButton (but not a
ttk.CheckButton)
A way of SETting the state of a ttk.CheckButton (but not a
tk.CheckButton)
Or the other way round. Or something else. I can no longer
remember, and I didn't keep a record of all my trials and tribulations,
and I can no longer trace which articles I read when.
EVENTUALLY I discovered:
For a ttk.CheckButton (only), where cb is the checkbox
cb.state() returns a tuple of strings which contains, or
doesn't, "selected", according to the checked state
cb.state(["selected"]) sets the checked state
cb.state(["!selected"]) clears the checked state
"Aha!" I thought. "Problem solved". Gleefully I wrote my code and
tested it.
Er, well, not quite. When the Checkbutton object was instantiated, it
showed neither a checked nor an unchecked box, but a solid black box.
This was the third or so-called "alternate" state provided by tkinter.
(Gee, thanks. Oh sorry, it's probably not your fault; as I understand
it, tkinter, you're really just a wrapper.)
Further research revealed that I could get past this by writing
cb.state(["!alternate", "!selected"])
when the object was instantiated.
Phew! Finally got my code working.
But the story is not quite over. To get the checked state I was using
"selected" in cb.state()
While this works, later (in fact while composing this e-mail) I stumbled
across
cb.instate(["selected"])
which does the same thing but is, I guess, the preferred method. I have
amended my code accordingly.
(I don't know why the square brackets are necessary, but
cb.instate("selected")
doesn't work.)
Sigh. I suppose I have the satisfaction of having overcome a
challenge. But how much nicer if all this information were in one place
somewhere.
Now, my remarks are as a tk newbie; they may be naive and ignorant,
perhaps even laughable. But IMO it is often worth listening to input
from newbies to consider how things might be improved.
Comments, anyone?
Better yet (holds breath ...) can anyone point me towards some decent
tkinter documentation?
Best wishes
Rob Cliffe
--
https://mail.python.org/mailman/listinfo/python-list
