This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Fix for tkFont.Font(name=...)
Type: Stage:
Components: Tkinter Versions: Python 2.3
process
Status: closed Resolution: accepted
Dependencies: Superseder:
Assigned To: loewis Nosy List: loewis, reowen, rhettinger
Priority: normal Keywords: patch

Created on 2003-07-01 21:14 by reowen, last changed 2022-04-10 16:09 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
tkfontdiff reowen, 2003-07-01 21:14 diff -c from 2003-06-30 cvs
tkfontdiff2 reowen, 2003-12-11 23:22 Second try to fix font from name
fontExample.py reowen, 2004-08-23 21:41 Sample script
Messages (12)
msg44185 - (view) Author: Russell Owen (reowen) Date: 2003-07-01 21:14
tkFont.Font(name=xxx) crashes if a font by the specified name already exists. This is a problem for several reasons, the main one being that it makes life really tough if you want to creat a new tkFont.Font object for a given Tcl named font.

This simple fix handles the problem.

I've also included a new method __eq__ so that two tkFont.Font objects that point to the same Tcl named font compare as equal. I felt this is important because the fix makes it easier to have multiple such tkFont.Font objects.
msg44186 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2003-07-13 15:32
Logged In: YES 
user_id=80475

The first part of the patch appears reasonable.  For the 
second part, it's a bit late for an API change.

Martin, is this bugfix okay for Py2.3?
msg44187 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2003-07-13 15:57
Logged In: YES 
user_id=21627

While the bug might be worth fixing, I think the approach
taken is wrong. With the patch, it will invoke "font names"
for all new tkFont objects, which might be a significant
overhead.

To really preserve current behaviour, it should continue to
'font create', and fall back to 'font configure' in case of
an exception.

Actually, it is not clear what the right behaviour is in the
first place. 'font configure' would change the settings of
the existing font. If the name clash is by coincidence, it
would be better to raise an exception instead of silently
modifying the existing font.

In the face of ambiguity, refuse the temptation to guess.

So to really fix this, tkFont.forName (or tkFont.existing)
should be provided.
msg44188 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2003-09-20 11:01
Logged In: YES 
user_id=21627

reowen, are you willing to revise the patch in this direction?
msg44189 - (view) Author: Russell Owen (reowen) Date: 2003-09-22 16:43
Logged In: YES 
user_id=431773

I'm quite willing to do more work on this. I agree with the criticisms (though I'm curious how name conflicts are presently handled for widgets when the name argument is used).

 I think the best solution for getting a font from a font name is "nameToFont". This matches the existing "nameToWdg". (I'd also like to add a "nameToVar" or "nameToVariable", so one standard mechanism handles everything, but I digress).

Unfortunately, tkFont is an add-on package. I'm not sure how tk.nameToFont can be written, given that normally a tk object won't automatically have any idea about fonts.

Do you have any suggestion for handling this? Could we just start importing tkFont as a standard part of Tkinter?
msg44190 - (view) Author: Russell Owen (reowen) Date: 2003-09-22 17:05
Logged In: YES 
user_id=431773

Here is a proposed approach to handle the exists problem. Supply a new argument to Font: exists. If False, the existing behavior is used; if True, existence is checked and the font configured (if any config info supplied). This makes it trivial to write "nameToFont" (it also makes it unnecessary, but I really think it is desirable).

The issue of how to make nameToFont a method of tk objects remains. I'd love to import tkFont (font objects should be more visible) but obviously permission is needed for such a step.

Anyway, what do you think? Is it permissable to add the "exists" argument to Font.__init__?
msg44191 - (view) Author: Russell Owen (reowen) Date: 2003-12-11 23:22
Logged In: YES 
user_id=431773

Here is another try that addresses the issues raisd by Martin Loewis. It adds a new argument to Font.__init__: exists. If False (the default) then the old behavior occurs unchanged (including an error is raised if the font already exists). If True, the font must already exist. This follows the dictum "explicit is better than implicit".

There is an another issue: what do do about Font's __del__? The existing behavior was for Font.__del__ to delete the associated tk named font. This causes trouble if more than one tkFont.Font object points to the same tk named font object. Even in the existing system it could also cause trouble if the user was doing a mixture of tk and Tkinter programming.

I see two solutions:
- Simple (what I did): do not delete tk named fonts (ditch Font.__del__). This makes it safe to mix tk an Tkinter programming. The only down side is increased memory use for any existing program that creates many tk named fonts and then deletes them. I can't imagine this is a serious issue.
- Fancy: keep a dictionary of each Font object (by font name) as it is created. If a new Font pointing to an existing tk named font is wanted, return the existing Font object. Then the old Font.__del__ is as safe as it ever was.
msg44192 - (view) Author: Russell Owen (reowen) Date: 2004-06-01 17:28
Logged In: YES 
user_id=431773

Just a tickle, hoping this can get into Python 2.4
msg44193 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2004-08-18 11:07
Logged In: YES 
user_id=21627

I have committed this change as tkFont.py 1.6, NEWS 1.1099.
I have left __del__; the font is now deleted in __del__ if
it was created in __init__.
msg44194 - (view) Author: Russell Owen (reowen) Date: 2004-08-23 20:14
Logged In: YES 
user_id=431773

Thank you very much for submitting this patch.

At risk of submarining this useful patch, I fear the __del__ 
change may be important.

The main point of the patch is so that Tkinter users can deal with 
a tk named font when all they have is the name. So...what can go 
wrong with deleting the tk named font when a tkFont object goes 
away?

Consider the following sequence:
- subroutine A creates a tkFont, which creates a new tk named 
font
- subroutine B knows the name of the font, but does not have the 
original tkFont object. So it creates a copy using name=...
- subroutine A finishes with the tkFont object and so it is garbage-
collected
- subroutine B's tkFont object mysteriously stops working because 
the underlying tk named font has been destroyed.

I found this sequence occurring in my own test code and it is the 
reason I deleted the __del__ object.

Other arguments for not deleting tk named fonts when tkFont 
objects go away:
- It is important if one has used named fonts to configure widgets 
(and this is the primary reason I know of for creating named 
fonts).
- It matches tk's own behavior.

I don't believe leaving tk fonts around has any significant down 
sides. One can certainly imagine memory use issues, but a user 
would have to create an unreasonable # of fonts to notice 
anything.

An alternative that requires more code is to use a dictionary to 
maintain a reference count by font name. When the count goes 
to zero, delete the tk named font. But yecch...
msg44195 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2004-08-23 20:34
Logged In: YES 
user_id=21627

Can you come up with a Python script that demonstrates the
problem with the deleted font, under the current CVS?
msg44196 - (view) Author: Russell Owen (reowen) Date: 2004-08-23 21:41
Logged In: YES 
user_id=431773

The sample script shows the basic issue. The setFontSize call 
should not have to know or care if the original tkFont object was 
destroyed or not. Unfortunately, with __del__ it dies if the original 
tkFont object is destroyed.
History
Date User Action Args
2022-04-10 16:09:36adminsetgithub: 38764
2003-07-01 21:14:43reowencreate