New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix for tkFont.Font(name=...) #38764
Comments
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. |
Logged In: YES The first part of the patch appears reasonable. For the Martin, is this bugfix okay for Py2.3? |
Logged In: YES While the bug might be worth fixing, I think the approach To really preserve current behaviour, it should continue to Actually, it is not clear what the right behaviour is in the In the face of ambiguity, refuse the temptation to guess. So to really fix this, tkFont.forName (or tkFont.existing) |
Logged In: YES reowen, are you willing to revise the patch in this direction? |
Logged In: YES 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? |
Logged In: YES 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__? |
Logged In: YES 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:
|
Logged In: YES Just a tickle, hoping this can get into Python 2.4 |
Logged In: YES I have committed this change as tkFont.py 1.6, NEWS 1.1099. |
Logged In: YES Thank you very much for submitting this patch. At risk of submarining this useful patch, I fear the __del__ The main point of the patch is so that Tkinter users can deal with Consider the following sequence:
I found this sequence occurring in my own test code and it is the Other arguments for not deleting tk named fonts when tkFont
I don't believe leaving tk fonts around has any significant down An alternative that requires more code is to use a dictionary to |
Logged In: YES Can you come up with a Python script that demonstrates the |
Logged In: YES The sample script shows the basic issue. The setFontSize call |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: