Bugs item #1563046, was opened at 2006-09-21 10:55
Message generated for change (Comment added) made by reowen
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563046&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Macintosh
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Russell Owen (reowen)
Assigned to: Ronald Oussoren (ronaldoussoren)
Summary: MacPython ignores user-installed Tcl/Tk
Initial Comment:
MacPython ignores any user-installed Framework Tcl/Tk. This is a
significant issue for Tcl/Tk users because the Tcl/Tk included with
Tiger is buggy and really shouldn't be used.
Bob Ippolito supplied me a recipe to fix _tkinter.so:
install_name_tool \
-change /System/Library/Frameworks/Tcl.framework/Versions/8.4/
Tcl \
/Library/Frameworks/Tcl.framework/Versions/8.4/Tcl \
-change /System/Library/Frameworks/Tk.framework/Versions/8.4/
Tk \
/Library/Frameworks/Tk.framework/Versions/8.4/Tk \
_tkinter.so
I encapsulated this recipe into the attached python script "fixtkinter.py",
which modifies _tkinter.so to use the user's Tcl/Tk, if found.
Please consider running this script while installing MacPython. If you
want any refinements to the script, I am happy to provide them (or feel
free to modify it yourself of course).
Subtleties:
- The script uses Carbon.Folder.FSFindFolder to find the "/Library/
Framework" directory, so it should work in any country.
- The script fixes the _tkinter.so for the python that executes the script
(finding it relative to the "os" module).
- The script silently exits without doing anything if no /Library/
Framework Tcl/Tk is found. Thus it is safe to run for all MacPython
installations.
- It can safely be run more than once; it silently does not modify
_tkinter.so file the second time.
- It finds the link using ...Tcl.Framework/Versions/Current but resolves
the link before modifying _tkinter.so. So if a user upgrades a major Tcl/
Tk version the _tkinter.so file will keep using the old version. I think this
is a good thing, since compatilibility is likely to be an issue.
- It only looks for a user-installed Tcl/Tk in "/Library/Frameworks"; it
does NOT look in the user's private library (~/Library). This was
intentional, but I'm not sure it was the right decision. I'm happy to
change it, but will want some advice on the best algorithm.
----------------------------------------------------------------------
>Comment By: Russell Owen (reowen)
Date: 2006-09-25 13:43
Message:
Logged In: YES
user_id=431773
I see what you mean about different installations. I think the following might
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 be used
(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 accidentally have 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 so bad), so I see this
as
more of an advantage than a disadvantage. Users aren't going to typically
install Tcl/Tk unless they want to use it, I think. Still...I'm sure you've
seen
more requests for help than I have over the years.
I'm not keen on including a Tcl/Tk for several reasons:
- 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 personally don't
want to try to build one.
- Which version would you use? Even 8.4.11 has some important known bugs,
and 8.4.13 has different ones (at least one of which is very nasty for my
application, so I stick with 8.4.11 for now).
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 in Tcl/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.
I also suggest ditching the python script (or simplifying it to just institute
Bob's recipe, but a shell script probably makes more sense for that job).
Note that Bob's recipe is in the comments at the top of my python script.
Thanks for the note about /Library/Frameworks. I had no idea it was a
universal name.
----------------------------------------------------------------------
Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-09-23 11:52
Message:
Logged In: YES
user_id=580910
If this gets used (and that's a big if at the moment) it should not look in the
users private library folder, because the system might be used by multiple
users and a system wide install should not use files that happen to be in the
home directory of one of them.
I don't like using this script during installation but would prefer a slightly
different solution: ship this script in /Applications/MacPython 2.5 and tell
users about it in our documentation (the installer documentation, the
pythonmac.org FAQ and possibly the tkinter docs).
If Tiger's copy of Tk is really bad enough to avoid using it completely we
should find a way to ship a minimal copy of Tcl/Tk with our installer
(installed
into /Library/Frameworks/Python.framework/Versions/2.5/Frameworks/
{Tcl,Tk}.framework), again with your script installed in the applications
folder
for people that want to use a bleeding edge copy of Tk.
I'm not to keen on automaticly using the copy of Tk in /Library/Frameworks
because of the support issue this raises: it is hard enough to debug problems
as it is without users haveing slightly different library versions.
BTW. Carbon.Folder.FSFindFolder is a nice touch but not actually necessary, /
Library/Frameworks is named like that in all languages, the name you see in
the Finder might be different but that's because the Finder localizes the
names of a number of folders (hence the ".localized" file in a number of
folders).
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1563046&group_id=5470
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
