Tkinter wart: bug or feature?

Mike Clarkson support at internetdiscovery.com
Mon Dec 2 03:23:25 EST 2002


On Mon, 18 Nov 2002 09:27:35 -0600, sismex01 at hebmex.com wrote:

>> From: support @ internetdiscovery.com [mailto:support @
>> internetdiscovery.com]
>>=20
>> On Sat, 16 Nov 2002 14:57:28 GMT, "Fredrik Lundh"
>> <fredrik at pythonware.com> wrote:
>>=20
>> >David Eppstein wrote:
>> >
>> >> ...or do all the ugly bookkeeping necessary to make sure=20
>> that image1
>> >> gets deleted when and only when it is no longer needed
>> >
>> >where all the "ugly bookkeeping necessary" is one extra line:
>> >
>> >    lbl =3D Tkinter.Label(win.window, image=3Dimage1)
>> >    lbl.photo =3D image1
>>=20
>> This is still a bug workaround, just like using global. You're still
>> expecting the end user to do ugly bookkeeping, but only for images:
>> I don't have to hold a reference to text1 global for it to work.  =20
>> No other commonly used entity in the Tkinter API has this
>> counter-intuitive behavior.  It's also very counter-intuitive to what
>> Tkinter is wrapping, namelyTk itself.
>
>I've been reading this thread, and it doesn't seem to be a bug
>really, but a compromise between the two distinct ways that Python
>and Tcl manage their objects; in Python, if you lose all references
>to an object, it automagically disappears (including images); in
>Tcl, if you lose all references to an image, it doesn't disappear,
>you can reclaim it v=EDa "calling it by it's name".

At first I thought this, but then I began to realize that it may be an
artifact of Tkinter's Image class. If Tkinter simply wrapped the class
to Tk's [image create] and [image delete] the way it wraps [image
names], then the problem goes away. Tk's [image create] returns a
string which the Tk widgets that have an image option recognize as
special. As I pointed out in my original message:

    image1 = win.tk.eval('image create photo -file %s'  % file)
    lbl = Tkinter.Label(win.window, image=image1)

works, so Tkinter could simply wrap this to something like:

    image1 = win.tk.image_createl('photo', file=file)

Fredrik may want an Image class in Tkinter for his own extentions, but
I don't see the need for it in this canonical type of usage.

>From: Eric Brunel <eric.brunel at pragmadev.com>
>
>Can someone please explain me why this cannot be done by the widget itself? 
>It seems to me that a line:
>
>if options.get('image') is not None: self.__image = options['image']
>
>at the right place(s) would do the trick. Am I missing something here?

That's right - you can do this for backwards compatability.  For the
widget's that have an image option, sublass their parent and override
the configure/setattr methods to hold a reference to the image that
is deleted when the widget is deleted. But I think it should be
deprecated in favour of a image_create('photo', file=file)

>From: "Fredrik Lundh" <fredrik at pythonware.com>
>
>if you do understand the problem, come up with a solution that works in
>all cases, is possible to maintain without too much work, and doesn't break
>existing code (including code that extends Tk/Tkinter, and images that are
>not represented by classes in the Tkinter module), and post the patch to
>sourceforge.

I'm sure it can be fixed - if you open it back up as a bug.

>if not, you have to live with the fact that people who know more than you
>thinks that this "evil wart" belongs to the "you'll only make this mistake once,
>and only if you don't read the documentation" category, and that there are
>more important things to work on.

The bug I was working on fixing was in code written by people by
people who know much more than me - the authors of the Tix wrapper,
probably the largest Tk wrapper outside of Tkinter. This bug had been
in the Python distribution for over a year. 

If you read the sourceforge documentation of the bug, you'll see that
I pointed out that this requirement to manually hold a reference to
images (but not other widget options) it is not documented in the
source code or library reference documentation. As a matter of fact, I
didn't see it documented in your Introduction to Tkinter either.
What the documentation does say is:

  "When trying to answer questions of the form ``how do I do blah'',
it is often best to find out how to do``blah'' in straight Tk, and
then convert this back into the corresponding Tkinter call. Python
programmers can often guess at the correct Python command by looking
at the Tk documentation. "

A self deleting image class clearly goes against this.

>given that your "obvious fixes" would break existing programs, it's pretty
>clear that you don't understand the problem very well.

If it gets reopened as a bug, I'm sure it will become clear that there
are fixes that would break nothing.  One thing that I am starting to
understand why it takes so long to get bugs fixed in Tkinter.

Mike.



More information about the Python-list mailing list