[Patches] [ python-Patches-764217 ] Fix for tkFont.Font(name=...)

[SourceForge.net]

Patches item #764217, was opened at 2003-07-01 14:14
Message generated for change (Comment added) made by reowen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=764217&group_id=5470

Category: Tkinter
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Russell Owen (reowen)
Assigned to: Martin v. Löwis (loewis)
Summary: Fix for tkFont.Font(name=...)

Initial Comment:
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.

----------------------------------------------------------------------

>Comment By: Russell Owen (reowen)
Date: 2003-09-22 10:05

Message:
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__?

----------------------------------------------------------------------

Comment By: Russell Owen (reowen)
Date: 2003-09-22 09:43

Message:
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?



----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-09-20 04:01

Message:
Logged In: YES 
user_id=21627

reowen, are you willing to revise the patch in this direction?

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2003-07-13 08:57

Message:
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.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-07-13 08:32

Message:
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?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=764217&group_id=5470