On Sep 25, 2006, at 11:08 PM, Russell E. Owen wrote:
In article <[EMAIL PROTECTED]>, Ronald Oussoren <[EMAIL PROTECTED]> wrote:As I noted in a comment in that bugreport I'm not to keen on that. I don't mind shipping the script ( or a GUI version of it) in the application folder for users that want to switch to a newer Tk, or even ship a minimal version of Tcl/Tk inside the Python.framework, but running this script during installation means that (a) the script must be 100% correct in all situations and (b) we'll end up with Python installations that are slightly different which won't be fun to investigate when someone reports a problem with tkinter. Especially because users might not even realize they have a copy of Tk in /Library/Frameworks.(I've posted a slightly longer version of this to the bug report):I see what you mean about different installations. I think the followingmight work better: - Always modify _tkinter.so to point to Tcl/Tk 8.4 in /Library/Frameworks. This will fall back to the built in /System/Library/Frameworks if the user has not installed an 8.4 of their own. It avoids a few of the issues you bring up and is simpler and more robust than what I originally suggested. Advantages: - All installations would be the same.- If the user installs a new Tcl/Tk after installing Python, it would beused (unless it's 8.5, which would not be safe to try with Python).
It still does not address your concern than a user might accidentallyhave a Tcl/Tk that they don't want to use. I'd personally be happier if users could easily upgrade their Tcl/Tk (since the installed one is sobad), so I see this as more of an advantage than a disadvantage. Usersaren't going to typically install Tcl/Tk unless they want to use it, Ithink. Still...I'm sure you've seen more requests for help than I have over the years.
I'm not that much of an old hand support-wise ;-). I have seen multipe problem reports that turned out to be caused by software that a user had lying around and either didn't know about or completely forgot about. And that includes users that are technically savvy.
I'm not keen on including a Tcl/Tk for several reasons: - Which version would you use? Even 8.4.11 has some important knownbugs, and 8.4.13 has different ones (at least one of which is very nastyfor my application, so I stick with 8.4.11 for now). - If a user wanted to upgrade their Tcl/Tk, what would they do? Theanswer is easy if we use the version of 8.4 found in /Library/ Framework(if any). - It can be tricky to add needed additions (my app uses the "snack" sound library, for example). A standard Tcl/Tk makes this much easier (and in fact ActiveState Tcl/Tk already includes all additions most folks would want).- There is no universal Tcl/Tk yet (though one is planned). I personallydon't want to try to build one.
That's a shame. Including some build of Tk has one advantage: users wouldn't have to install Tk on Panther just to be able to use IDLE. If there is no universal build of Tcl/Tk available I'm definitely not going to spent time on trying to build one.
BTW. Versiontracker claims 8.4.13 is avaible as a universal binary although tcltkaqua doesn't mention the 8.4.13 release at all. The download for 8.4.13 seems to be from the tk-components project on SF.
So my personal suggestion is that we modify _tkinter.so using Bob Ippolito's recipe unchanged (no fancy script that hunts for an installed Tcl/Tk). It will be completely compatible with the built inTcl/Tk but gives any real users of Tcl/Tk (anyone who isn't just writing"hello world") a trivial way to get a decent version.
What's the opionion of other Tk-using python users? I don't use tkinter on OSX because aquatk sucks in the L&F department and are hence happy with the current status quo (aka "IDLE works").
Ronald
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
