Update tcl/tk/tix versions

[7cddcdb8-70c4-48ae-bf34-c9cedc76ace6]

BPO	409044
Nosy	@gvanrossum, @loewis
Files	Setup.dist.diff.gz: Modules/Setup.dist context diff

^{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: ```python assignee = 'https://github.com/gvanrossum' closed_at = created_at = labels = ['expert-tkinter'] title = 'Update tcl/tk/tix versions' updated_at = user = 'https://bugs.python.org/idiscovery' ``` bugs.python.org fields: ```python activity = actor = 'gvanrossum' assignee = 'gvanrossum' closed = True closed_date = None closer = None components = ['Tkinter'] creation = creator = 'idiscovery' dependencies = [] files = ['3192'] hgrepos = [] issue_num = 409044 keywords = ['patch'] message_count = 6.0 messages = ['36062', '36063', '36064', '36065', '36066', '36067'] nosy_count = 3.0 nosy_names = ['gvanrossum', 'loewis', 'idiscovery'] pr_nums = [] priority = 'low' resolution = 'accepted' stage = None status = 'closed' superseder = None type = None url = 'https://bugs.python.org/issue409044' versions = [] ```

[7cddcdb8-70c4-48ae-bf34-c9cedc76ace6]

A small patch to Modules/Setup.dist to update the Tix version to the current tix8.1.8.2 library.

Also, it may be important when adding Tcl extensions like Tix to define -L/usr/local/lib *before* any possible libraries like -ltix8.1.8.2. Linux will silently pick up other installed versions of the -l libraries defpending on the ld.so settings.

The attached context diff is against 2.1b1, but it should apply to any 2.x version.

[61337411-43fc-4a9c-b8d5-4060aede66d0]

Logged In: YES user_id=21627

I believe Tix integration should not rely on static linkage anymore. Instead, you should do

  self.tk.eval("package require Tix") 

and rely on Tix being loaded as a dynamic Tk extension. If you agree, I'd rather encourage ripping out the Tix "support" in setup.py, Setup, and all other locations.

Are you using a wrapper module Tix.py? If so, *that* would be a good addition, and it would also be the place where dynamic loading of Tix is attempted.

[7cddcdb8-70c4-48ae-bf34-c9cedc76ace6]

Logged In: YES user_id=33229

I would love to load Tix using package require, because that would be a "good thing", but there are some details:

1) _tkinter.c is written to declare static packages. I just followed that route for consistency. Perhaps there is no need, and _tkinter.c should be just rewritten and recommented to advise using packages. 2) I don't think [package require] will work with Freeze.py - it must be loaded static, and hence the current setup works with Freeze. 3) i think the current Windows .dsp files also imply static linking.

My feeling is that we need to move the whole Tcl/Tk/Tix setup towards stubs first, then [package require], but there are a lot of platforms and combinations that need testing. And I really think we should discuss this in the newsgroup to get Cameron Laird and Jeff Hobbes involved.

I also have *extremely grave reservations* about setup.py. I think I understand what it's trying to do, but I think its probably a bad approach:

1) The algoritm for finding libraries differs from the OS, which differs from OS to OS. This is even for static linking (see my original comment on -L), and 100 times worse for dynamic. 2) It hides what used to be user controlled (edit Setup) under magic. 3) The "right way" would be to have configure --with-tk ... and then have setup.py pick up info out of config.status. 4) I don't see where setup.py edits _tkinter.dsp for cross platform consitency. 5) I don't see where setup.py ties in with ActiveState's new approach.

These are all cans of worms, so my thought was: put Tix in as static, and get the documentation in, for the next bug fix release. Then raise the whole issue of stubs->package require->frozen in the newsgroup, and get the issue properly explored.

Don't hesitate to send me email as well idiscovery@users.sourceforge.net

Mike.

[61337411-43fc-4a9c-b8d5-4060aede66d0]

Logged In: YES user_id=21627

For 1), I'd say this is historic garbage (I added some of it myself), so don't be afraid to rip it out. tkappinit.c predates the times that Tcl could do dynamic loading. Also, there is no need to operate the same way for all packages; just fix Tix for now.

For 2), there are more problems when freezing: In Python 2.1, setup.py will build _tkinter as a dynamic module, and you can't freeze them, anyway. So anybody who wants to freeze would need a build where _tkinter is listed in Modules/Setup. Furthermore, you typically need Tix SAM libraries, or else the binary won't be stand-alone. Then you need static versions of libtcl.a, not shared ones. Anybody who wants to freeze with Tix needs a fair amount of local configuration, so supporting freeze is more complicated.

For 3), if Tix does not appear in the C files at all, it can be removed from the .dsp file as well.

For setup.py: You still can use Setup if you want to.

The problem I see with static linkage that _tkinter then depends on Tix, so to install Python, you'll need to install Tix first; if you build Python not to depend on Tix, you can't use it even when it gets installed. Since most people use binary distributions, they get more out of dynamic loading than they'd get from static linking.

[7cddcdb8-70c4-48ae-bf34-c9cedc76ace6]

Logged In: YES user_id=33229

The "Tix" patches have been resubmitted as bpo-410231, and all of the suggestions here have been incoproated (dynamic loading, package require, Tkinter.Widget.__bases__).

But this patch still remains valid for all Tk extensions, even for 2.0.x, as the -L must proceed *any* -l. Also, tix4.1.8.0 was never an official release, and most Linux releases are now distributing tix8.1.8.x.

[gvanrossum]

Logged In: YES user_id=6380

Checked in.