Tkinter status bar?

Matthew Dixon Cowles matt at mondoinfo.com
Tue Sep 24 23:05:41 EDT 2002


On Wed, 25 Sep 2002 01:41:36 GMT, Daniel T. <a at b.c> wrote:

> I'm going through a pdf file I found on the internet ("An
> Introduction to Tkinter" by Fredrik Lundh)

Fredrik's Introduction is excellent. I almost always have a copy open
when I'm doing Tkinter programming.

> In chapter 8 he talks about how to put a status bar at the bottom of a 
> window:
> 
> # File: tkSimpleStatusBar.py
> class StatusBar(Frame):

[. . .]

> We could have inherited from the Label widget itself, and just
> extended it with set and clear methods. This approach have a few
> drawbacks, though:

[. . .]

> Now my question. I didn't think to inherit from Label, instead I
> changed it to:

> class StatusBar:
>    def __init__(self, master):
>       self.label = Label(master, text="", bd=1, relief=SUNKEN,
>         anchor=W)

[. . .]

> In other words, why inherit from any of the Tkinter classes?

No reason. I generally don't. You can do it either way depending on
your personal preference and/or the details of the class you're
defining.

If what you're doing feels like it's refining the behavior of an
existing class, I'd say that inheritance makes sense. If it feels like
you're creating a new class, I'd say that wrapping one or more
existing widgets (as you're suggesting doing) and delegating calls to
them makes sense. Other people have other rules of thumb, I'm sure.

Delegating calls to wrapped objects can be more verbose if you need
to delegate lots of them. But I find that I don't generally need to
delegate lots of calls and to my eye it's more explicit.

Regards,
Matt



More information about the Python-list mailing list