[Tutor] Tkinter in classes...why?

[Alan Gauld]

Elwin Estle" <chrysalis_reborn at 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/