[Pythonmac-SIG] Why Do I Explicitly Need MacPython

[Ronald Oussoren]

On Sep 25, 2006, at 11:08 PM, Russell E. Owen wrote:

> In article <944DAEC0-8EAB-4DC8-A98E-457DF3B657C8 at mac.com>,
>  Ronald Oussoren <ronaldoussoren at mac.com> 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  
> 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 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 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).
> - If a user wanted to upgrade their Tcl/Tk, what would they do? The
> answer 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  
> personally
> don'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 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.

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3562 bytes
Desc: not available
Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060926/dc097c71/attachment.bin