[Tutor] Tkinter in classes...why?
Elwin Estle
chrysalis_reborn at yahoo.com
Thu Jan 20 20:43:06 CET 2011
I have some experience in Tcl\Tk, and so far, Tkinter is striking me as harder to use that Tk in it's "native" environment.
I am attempting to re-write a program I originally did in Tcl\Tk in Python. I managed to get a GUI done using just Tkinter, and, after an initial struggle with the Tkinter syntax (and especially the widget "naming" conventions), had no problem getting widgets to display, etc.
But, the tutorials I have encountered all mentioned that it is supposed to be a good idea to put one's GUI stuff in a class, then create an instance of the class (which I don't entirely understand, since I thought the whole "class" thing was for stuff that you were gonna have a lot of, like similar records in a database or something, so you could use the class like a factory to spit out little copies of itself.
Anyway, when I attempted to convert my non-class based Tkinter code into a class, that's when the problems started. I guess I still don't have a handle on all the "self.this's & self.that's", tho I have created some classes for the aforementioned database entry type stuff and haven't had too much trouble.
For starters, it seems like the first thing these class based tutorials do is to start with a frame inside the main Tkinter window? Why? Why not just grid stuff right into the window, instead of making a frame and gridding widgets into that.
Is the (self, master) thing in the __init__ section a convention, or is the use of the "master" a requirement? Can you call it something else? What is the purpose of doing an __init__ with a frame after having done __init__ with (self, master)?
All this in Tcl\Tk seems to me, in comparison, just dead nuts simple...but Tkinter...seems to have made unnecessarily complicated. Maybe once I understand it, I won't think of it that way, but for now...whatta PITA!
More information about the Tutor
mailing list