Elwin Estle" <chrysalis_reb...@yahoo.com> wrote
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.
They are actually very similar although Tkinter is a little more verbose. Remember that Tk uses objects too, its just that they are less visible.
When you create Tk widgets you define them using a tree of objects rooted at '.' But there are good reasons to use OOP in building GUIs regardless of the Framework - and even many Tcl/Tk programmers use tools like [incr Tcl] to build OOP GUIs using Tk...
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,
Not necessarily a lot of but things you may want to reuse. And Guis are full of things you can reuse like Forms, Dialogs, composite widgets etc. By packaging them as a class based on a Frame its as easy to reuse them as just adding a new Frame to your app. And you bring in all the entries, radio buttons ,labels etc that you need for free. As well as the event handlers for the class. (This is also the main reason you should try to keep app logic out of your GUI event handlers!)
use the class like a factory to spit out little copies of itself.
Yep, lots of nreuase of login widgets, file editing widgets etc etc. Much easier to reuse than writing GUI functions in Tk and trying to import them into another project. Also, visually its an easy mapping to make in your head to see a widget or panel on screen and associate it with the class code behind it. GUI widgets are conceptually objects so we might as well make them software objects too.
I still don't have a handle on all the "self.this's & self.that's",
Yeah OOOP does take a little getting used too. But you had to get used to TK's arcane naming tree too, once mastered its all pretty logical.
Why not just grid stuff right into the window, instead of making a frame and gridding widgets into that.
Because a Frame is a container that allows you to reuse that whole panel. packing(or gridding if you prefer) loses you the reuseability.
Is the (self, master) thing in the __init__ section a convention,
Its the Tkinter equivalent of using '.' to start your naming tree in Tk. The master is passed to a hideen attribute inside the widget which maintains the links up the tree. Tk just does that explicitly via the name.
or is the use of the "master" a requirement? Can you call it something else?
You can call it whatever you like in most cases - its a bit like self in a class definition. You can change it if you want but I don't recommend it - you will confuse anyone reading the code (including, possibly yourself!) but I have seen "parent" used in some programs.
What is the purpose of doing an __init__ with a frame after having done __init__ with (self, master)?
The self,master is usually to the superclass. The rest of init is about the current object. If that makes no sense you need to go back to the OOP primers because its no different in Tkinter than elsewhere in that regard.
All this in Tcl\Tk seems to me, in comparison, just dead nuts simple...but Tkinter...seems to have made unnecessarily complicated.
You can write Tkinter code exactly like Tk but you lose the reuse and logical organisation advantages that OOP brings. But Tkinter works just fine without OOP. But using OOP with Tkinter will make the jump to other, more powerful, GUI frameworks later, much, much easier because they all use OOP, almost without exception (unless you count raw Win32!). HTH, -- Alan Gauld Author of the Learn to Program web site http://www.alan-g.me.uk/ _______________________________________________ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor
