| msg45095 - (view) |
Author: David Ascher (david_ascher) *  |
Date: 2004-01-02 18:22 |
| Two things: 1) docstrings added to most attributes of the _tkinter app object 2) allow the user to create Tkinter.Tcl objects which are just like Tkinter.Tk objects except that they do not initialize Tk. This is useful in circumstances where the script is being run on machines that do not have an X server running -- in those cases, Tk initialization fails, even if no window is ever created. I'll be glad to discuss the implementation choices. This has been tested on Windows, Linux, and Solaris. I'm hoping to figure out how to attach the test file as well. I don't have any documentation patch -- I'm willing to contribute one, but given the state of Tkinter documentation am not sure where to start... |
|
|
| msg45096 - (view) |
Author: Martin v. Löwis (loewis) *  |
Date: 2004-01-03 11:58 |
| Logged In: YES user_id=21627 The patch looks fine, please apply. As for documentation: it has been custom to just document the changes (and perhaps write the bare minimum of structure to add the changes) to lib/tkinter.tex. I see no problem with some features being documented and others not - over time, documentation will complete if we continue with this custom. I wonder whether the loading of Tk can be simplified as evaluating "package require Tk" instead of calling Tk_Init(); I don't know what the difference between these two is. |
|
|
| msg45097 - (view) |
Author: Jeff Epler (jepler) |
Date: 2004-01-04 17:21 |
| Logged In: YES user_id=2772 I think that "package require Tk" is commonly broken. It is on RedHat 9 and Fedora Core 1. [jepler@parrot]$ tclsh % package require Tk can't find package Tk |
|
|
| msg45098 - (view) |
Author: David Ascher (david_ascher) * |
Date: 2004-02-18 06:03 |
| Logged In: YES user_id=6114 Checked in. |
|
|
| msg45099 - (view) |
Author: Guido van Rossum (gvanrossum) * |
Date: 2005-07-24 23:32 |
| Logged In: YES user_id=6380 There seems to be a problem with this patch. It introduces __getattr__, __hasattr__ and __delattr__ methods, which attempt to delegate attributes to the self.tk object if they aren't defined on self. This is fine for __getattr__. __hasattr__ is based on a misunderstanding; there is no special __hasattr__ method. Butthe real problem is __delattr__ -- remember the asymmetry between __getattr__ and __setattr__? __getattr__ is only called as a fall-back (when the attribute isn't found using the normal attribute search), but __setattr__, if defined, is *always* called. Well, __delattr__ behaves the same way as __setattr__. The end result is that if someone sets a private attribute on a Tk() instance, it can be set (because __setattr__ is not defined) cannot be deleted (because __delattr__ is). Why do I care? It breaks Tkdnd! Tkdnd stores a private attribute (__dnd) on the Tk() object to indicate that it is active, and deletes it to indicate that it is no longer active. The fix is easy from my perspective: just get rid of the __hasattr__ and __delattr__ methods. But I'd like to ask the author and reviewer of the patch if they remember why this delegation was added in the first place, and if there's something that might be broken by my proposed fix. |
|
|
| msg45100 - (view) |
Author: David Ascher (david_ascher) * |
Date: 2005-07-26 22:50 |
| Logged In: YES user_id=6114 I'm fine w/ the proposed fix. I don't recall the reason for the delegation, but the proposed logic seems fine. Apologies for the bug. |
|
|
| msg45101 - (view) |
Author: Guido van Rossum (gvanrossum) * |
Date: 2005-07-27 00:00 |
| Logged In: YES user_id=6380 OK, fixed in 2.4 and CVS head. |
|
|