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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2023-05-24, Rob Cliffe via Python-list <python-list@python.org> wrote:

I have recently started converting a large project to tkinter, starting
with zero knowledge of tkinter.  (You are free to think: BAD IDEA. 😁)

Well, you could be translating them to Tcl/Tk -- so on the scale of
bad ideas, your's barely registers.

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.

Back in the day, the Grayson book was the definitive reference:

https://www.amazon.com/Python-Tkinter-Programming-John-Grayson/dp/1884777813/

It's 20+ years old now, so the version of Python it uses is pretty
ancient, and I presume Tk has also changed a bit over the years, so...

There are a couple recent books, but I haven't looked at them:

https://www.amazon.com/Modern-Tkinter-Busy-Python-Developers-dp-1999149564/dp/1999149564/

https://www.amazon.com/Python-GUI-Programming-Tkinter-user-friendly/dp/1801815925/

--
Grant

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 5/23/23 21:18, Rob Cliffe wrote:

Comments, anyone?
Better yet (holds breath ...) can anyone point me towards some decent
tkinter documentation?

The variables are slightly more integrated when using tcl/tk directly,
python has to have the object so you can track/use them easier. And the variables are more of what is intended to track a widgets purpose, vs
state stuff that is more the state of the displaying of the widget.

occasionally giving tcl/tk a try directly helps, and using the official
tcl/tk docs in addition to a couple other decent docs below.

https://anzeljg.github.io/rin2/book2/2405/docs/tkinter/index.html https://tkdocs.com/tutorial/styles.html

https://www.tcl.tk/man/tcl8.6/ https://www.tcl.tk/man/tcl8.6/TkCmd/contents.html https://www.tcl.tk/man/tcl8.6/TkLib/contents.html

(this used to be some documentation that I only discovered existed
recently, but most of it doesn't load and I don't know that anyone
backed it up for rehosting..) https://web.archive.org/web/20200227170827/http://effbot.org/tkinterbook

tk is decent for what it can do, (and it could do potentially more if
you had a lifetime to dedicate to it, lol) and it's reasonably stable
and not being perpetually hacked about and broken like gtk.

A couple additional pointers in case these haven't been figured out yet: Running it interactively and using tab complete helps.
If you are running an app you can comment out the mytk.mainloop()
statement then run python -i yourtk.py to give you access to all widgets
live.
For navigating them, just come up with a widget naming convention that
works for you in a similar vein to how tk does (like .frame.frame.label
to start),
i.e.
main = tk.Tk()
main.frame = tk.Frame()
That way if you have anchored your widgets to something at the root
level you can navigate down to whatever you are looking for easily. (you
can also use winfo_children() iteratively to travel the way tcl
structures them, but that is tedious).

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am 24.05.23 um 03:18 schrieb Rob Cliffe:

I have recently started converting a large project to tkinter, starting
with zero knowledge of tkinter.  (You are free to think: BAD IDEA. 😁)

Welcome to the awesome world of GUI development.

    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.

As you found out the hard way, it is possible, but then you dive into
the internals of how the widgets work - usually you don't want to know
that. Also, this bit differs between Tk and Ttk widgets.

[...] lengthe description of Checkbutton internals

In GUI programming, you will meet a bag of concepts that you haven't
seen in sequential programming before. To make it worse, every GUI
toolkit brings its own new set of concepts to the table. Maybe it is
helpful to work through a Tk tutorial first. This is a good one:

http://tkdocs.com/tutorial/index.html

Similarly to the tutorial I would suggest to stick with the ttk widgets.
Those are an "update" (> 10 years ago) to the tk widgets and are
supposed to provide sensible defaults matching the users experience with
native GUI elements. There are only 3 widgets where you must use a Tk
widget, this is Text (for multiline formatted text entry), Canvas (for
2D drawings), and Toplevel (for new windows/ popups etc.)

Christian

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 24 May 2023 at 13:11, Rob Cliffe via Python-list <python-list@python.org> wrote:

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.

Yes, I do think this is a bad idea, though not an abysmal one. I would recommend first playing with tkinter in a dedicated UI-only project
before converting the main project to it. Your code in the scratch
project can be as messy as it likes, and then you learn from it before
tackling the big one :)

But your concerns about tkinter's documentation are, sadly,
well-founded. Since it's this weird system of thin wrappers around
Tcl/Tk, a lot of things are basically just "go read the Tk docs".
There are a few key concepts you'll need to get your head around, and
I can't go into details because I never truly got *my* head around
them... but mostly, the way that variables are used and what happens
when events fire.

Good luck with it. I'll be frank, building a GUI can be pretty hard...
I'm still unsure whether the best way is to use something like
tkinter, or to build a web app, pop up a browser window, and establish
a websocket to communicate between your JavaScript front end and your
Python back end. Yeah, that's how bad GUI building can be sometimes -
it is potentially *easier* to build two halves of your app in two
different languages than to make your GUI work the way you want it.

ChrisA

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 24May2023 02:18, Rob Cliffe <rob.cliffe@btinternet.com> wrote:

    There doesn't seem to be any decent documentation for it anywhere.

Already mentioned in the replies, I use this: https://tkdocs.com/shipman/index.html
quite a lot.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Thanks to everyone who replied.  All replies were constructive, none
were telling me to stop belly-aching.
I forgot/omitted to state that it was I who wrote the original project
(in a completely different language), making the task of re-writing it
much less formidable.  And meaning that I am familiar with the general concepts of building a GUI.  Still, it will be a lot of work.

Grant, I may well buy one of the books you suggested.
I find the topic of themes and styles the hardest one to get my head
around (if anyone knows a good introduction that would be fantastic). 
All the other stuff is OK provided I can find something on the net to
give me the necessary information, which so far I usually can.

Christian, I am adopting your suggestion of using ttk widgets, except
for Button objects, because
    The colour of tk.Button objects can be set directly (bg=... fg=...)
    On my platform (Windows10) the shadowing of tk.Button objects is
more conspicuous (without using styles or whatever).

Best wishes
Rob Cliffe

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2023-05-26, Rob Cliffe via Python-list <python-list@python.org> wrote:

Grant, I may well buy one of the books you suggested.

I haven't had look at either of the newer books, but I got a lot of
good out of the Grayson book (20 years ago). I also had a Tcl/Tk book
that I found useful even when usng tkinter, but it's even older than
the Grayson one...

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)