Repository navigation
Update tkinter to use Tk 8.6.15 or (better) Tk 9.0 #124111
Copy link
Copy link
Closed
Labels
extension-modulesC modules in the Modules dirC modules in the Modules dirtopic-tkintertype-featureA feature request or enhancementA feature request or enhancement
Description
Feature or enhancement
Proposal:
This issue is being opened as a prerequisite for a PR which will update _tkinter.c and Lib/test/test_tkinter so that they work with both Tk 8.6.15 and Tk 9.0.
Both Tk 8.6.15 and Tk 9.0 currently have release candidates available and will be released soon. The TclTk project has decided that there will be no release of the 8.7 branches. Tcl 9 and Tk 9 are the current development branches (both named main in the fossil repository.)
Tk 9 offers many improvements over Tk 8, and both TclTk and Python would benefit from having tkinter support for Tk 9.0.
Has this already been discussed elsewhere?
No response given
Links to previous discussion of this feature:
No response
Linked PRs
- gh-124111: Update tkinter and test_tkinter to use either Tcl/Tk 8.6.15 or Tcl/Tk 9.0. #124112
- gh-124111: Update tkinter for compatibility with Tcl/Tk 9.0.0 #124156
- [3.13] gh-124111: Update tkinter for compatibility with Tcl/Tk 9.0.0 (GH-124156) #127364
- gh-124111: Fix TCL 9 threaded detection #128103
- gh-124111: Update macOS installer to use Tcl/Tk 8.6.16. #132190
- [3.13] gh-124111: Update macOS installer to use Tcl/Tk 8.6.16. (GH-132190) #132198
- [3.12] gh-124111: Update macOS installer to use Tcl/Tk 8.6.16. (GH-132190) #132199
- gh-124111: test macOS CI with Tk 9 #136959
- gh-124111: test macOS CI with Tk 9 #137424
- gh-124111: Update macOS installer to use Tcl/Tk 8.6.17. #139682
- [3.14] gh-124111: Update macOS installer to use Tcl/Tk 8.6.17. (GH-139682) #139683
- [3.13] gh-124111: Update macOS installer to use Tcl/Tk 8.6.17. (GH-139682) #139684
- gh-124111: Update macOS installer to use Tcl/Tk 9.0.2. #140076
- [3.14] gh-124111: Fix TCL 9 thread detection (GH-128103) #141482
- [3.13] gh-124111: Fix TCL 9 thread detection (GH-128103) #141483
- gh-124111: Update macOS installer to use Tcl/Tk 9.0.3 #144646
- gh-124111: Fix tclWin32Exe value in tcltk.props for Tcl 9 #149441
- gh-124111: Only set TCLSH_NATIVE for AMD64/ARM64 #149443
- [3.14] gh-124111: Update macOS installer to use Tcl/Tk 9.0.3. #149463
- gh-124111: Update Windows build to use Tcl/Tk 9.0.3 #149477
- [3.15] gh-124111: Update Windows build to use Tcl/Tk 9.0.3 (GH-149477) #149842
- gh-124111: Keep tests passing for Tcl prior to 9.0 #150102
- [3.15] gh-124111: Keep tests passing for Tcl prior to 9.0 (GH-150102) #150110
- [3.14] gh-124111: Update Windows build to use Tcl/Tk 9.0.4 (GH-150102) (GH-149477) (GH-151562) (GH-153901) #150197
- [3.13] gh-124111: Update macOS installer to use Tcl/Tk 8.6.18. #151125
- gh-124111: Update macOS installer to use Tcl/Tk 9.0.4. #153868
- [3.14] gh-124111: Update macOS installer to use Tcl/Tk 9.0.4. (GH-153868) #153870
- [3.15] gh-124111: Update macOS installer to use Tcl/Tk 9.0.4. (GH-153868) #153871
- gh-124111: Update Windows builds to Tcl/Tk 9.0.4 #153901
- [3.15] gh-124111: Update Windows builds to Tcl/Tk 9.0.4 (GH-153901) #153990
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
extension-modulesC modules in the Modules dirC modules in the Modules dirtopic-tkintertype-featureA feature request or enhancementA feature request or enhancement
Activity
pythongh-124111: Update tkinter for compatibility with Tcl/Tk 9.0.0 (p…
vstinner commentedon Nov 28, 2024
I'm interested by a backport of the change 47cbf03 to 3.12 and 3.13 branches. In Fedora Rawhide, we have Tcl/Tk 9 and Python 3.12 and 3.13. It would be nice to support recent Tcl/Tk in stable Python versions.
I started by creating PR gh-127364 which is a simple backport from main to 3.13 branch: there is no merge conflict!
cc @hroncok
pythongh-124111: Update tkinter for compatibility with Tcl/Tk 9.0.0 (p…
cho-m commentedon Dec 19, 2024
With TCL 9, CPython's _tkinter.c thread support detection doesn't seem to work:
cpython/Modules/_tkinter.c
Lines 586 to 587 in f802c8b
I'm guessing this is due to documented TCL change:
Current (main)
_tkinter.ccode causes crashes when mixing threading and tkinter probably from TCL APIs executed on the wrong thread.Crash goes away by forcing
v->threaded = 1;withTCL_MAJOR_VERSION >= 9(orTK_MAJOR_VERSION >= 9).pythongh-124111: Fix TCL 9 threaded detection
pythongh-124111: Update tkinter for compatibility with Tcl/Tk 9.0.0 (p…
pythongh-124111: Update macOS installer to use Tcl/Tk 8.6.16.
Merge branch 'main' into pythongh-124111-tcltk8616-macos-installer-main
gh-124111: Update macOS installer to use Tcl/Tk 8.6.16. (#132190)
pythongh-124111: Update macOS installer to use Tcl/Tk 8.6.16. (python…
pythongh-124111: Update macOS installer to use Tcl/Tk 8.6.16. (python…
[3.12] gh-124111: Update macOS installer to use Tcl/Tk 8.6.16. (GH-13…
[3.13] gh-124111: Update macOS installer to use Tcl/Tk 8.6.16. (GH-13…
aivarannamaa commentedon May 6, 2025
Any idea, whether Tk 9.0.1 will appear in Python 3.14 official builds?
ned-deily commentedon Jul 22, 2025
Now that Tk 9.0.2 has been released, I have built and tested a macOS Python with it using the current main (3.15) branch (on a current macOS Sequoia 15.5 Apple Silicon system). I'm seeing 25 failures (a number appear to be the same failure just with different widgets). The current 3.14 branch (just prior to rc1) gives similar results. FTR, 3.13 has many more failures as the original fixes for Tk 9 have not been backported. I have not tested on any other platforms. Tcl and Tk were built on macOS 15.5 with
CFLAGS="-mmacosx-version-min=10.15 -arch arm64 -arch x86_64".At the moment, our GitHub CI tests for macOS are pinned to the current Homebrew tcl-tk@8 package, currently 8.6.16, avoiding this issue. AFAICT, most of our CI runs and buildbots build with Tk 8.6, a few with 9, but very few of any of them actually execute the GUI tests on any platform; the macOS
build and test (macos-13)CI job is one that does execute them. It would be good if more did.The failing test cases in alphabetical order:
and the detailed test failures:
culler commentedon Jul 22, 2025
Thank you, Ned!
These are familiar-looking, easy-to-fix and not unexpected errors. They are not unexpected because there has been an effort
to handle all options which represent screen distances in a consistent way, and to use the new "pixel" object type where appropriate. The Tk changes translate into tkinter test failures where
In my pull request I fixed many failures of these types and tried to set things up so that fixing others would be easy. But Tk did not adjust all of these options in one big change; Instead it was done one widget at a time. A number of options have been modified since the time when my PR was accepted.
Fixing one of these is a minor change - it involves a standard change or addition of one attribute of one of the test classes.
As far as I know, this project to handle screnn distances consistently is now finished. So this won't need to be repeated for every release of Tk 9.0.X. (or Tk 9.1.X). Note that the 9.0 series is transitional and will end in 2026. But I don't think any changes will be needed to tkinter to migrate from 9.0 to 9.1. I am currently using the same tkinter code with both 9.0 and 9.1.
pythongh-124111: test macOS CI with Tk 9
Revert "pythongh-124111: test macOS CI with Tk 9"
hugovk commentedon Aug 5, 2025
Please could you check PR #137424?
python313Packages.tkinter: revert to building with tcl 8.6
python313Packages.tkinter: revert to building with tcl 8.6
python313Packages.tkinter: revert to building with tcl 8.6
gh-124111: Update macOS installer to use Tcl/Tk 8.6.17. (#139682)
pythongh-124111: Update macOS installer to use Tcl/Tk 8.6.17. (python…
pythongh-124111: Update macOS installer to use Tcl/Tk 8.6.17. (python…
[3.13] gh-124111: Update macOS installer to use Tcl/Tk 8.6.17. (GH-13…
[3.14] gh-124111: Update macOS installer to use Tcl/Tk 8.6.17. (GH-13…
pythongh-124111: Update macOS installer to use Tcl/Tk 8.6.17. (python…
Merge branch '3.15-pythongh-124111-macos-ci-tk9' into 3150a0+pre
Merge branch 'main' into 3.15-pythongh-124111-macos-ci-tk9
gh-124111: test macOS CI with Tk 9 (#137424)
pythongh-124111: Update macOS installer to use Tcl/Tk 9.0.2.
gh-124111: Update macOS installer to use Tcl/Tk 9.0.2. (#140076)
aivarannamaa commentedon Oct 27, 2025
I see that macOS installer of 3.15 now uses Tcl/Tk 9.0.2. Thank you!
What's the state with the Windows installer? Are there some blockers or it just needs to be updated? Any hope it will land in 3.15a2?
terryjreedy commentedon Oct 30, 2025
The current releases of 3.12 - 3.15 have 8.6.15 so that is no longer a blocker.
culler commentedon Oct 30, 2025
I don't think there is a blocker. Just inertia.
gh-124111: Fix TCL 9 thread detection (GH-128103)
pythongh-124111: Fix TCL 9 thread detection (pythonGH-128103)
pythongh-124111: Fix TCL 9 thread detection (pythonGH-128103)
[3.14] gh-124111: Fix TCL 9 thread detection (GH-141482)
[3.13] gh-124111: Fix TCL 9 thread detection (GH-141483)
Merge branch 'main' into fix-issue21914
Merge branch 'main' of github.com:python/cpython into fix-Issue18387
Merge branch 'main' of github.com:python/cpython into fix-issue24255
pythongh-124111: Fix TCL 9 thread detection (pythonGH-128103)
pythongh-124111: Update macOS installer to use Tcl/Tk 9.0.3
gh-124111: Update macOS installer to use Tcl/Tk 9.0.3 (#144646)
pythongh-124111: Update macOS installer to use Tcl/Tk 9.0.3 (python#1…
ThingamabobsCoding commentedon Feb 23, 2026
I'm looking forward to use tkinter 8.7 since 2021 and today is the day I may ask if there is a release in sight?
pythongh-124111: Update macOS installer to use Tcl/Tk 9.0.3 (python#1…
maj113 commentedon May 3, 2026
Any news on this? Tkinter for Windows is still on 8.6.x
picnixz commentedon May 3, 2026
cc @zooba
ajkessel commentedon May 4, 2026
Just to chime in: there is no easy way to build a Mac universal2 python app that relies on Tk and will be accepted by the App Store. The problem is that Tkinter 8.6 unnecessarily includes a symbol for a deprecated API, so the App Store will reject the submission. The problem is discussed here. The workaround takes some work -- I just recently published a script here as a temporary solution. Having Python universal2 with Tk 9 support would eliminate this problem and make it much easier to build Python apps for the App STore.
maj113 commentedon May 4, 2026
I thought MacOS is already on Tk/tcl9.0.3
ned-deily commentedon May 4, 2026
As of this moment, the current macOS python.org installers for Python 3.13.x and 3.14.x still use Tk 8.6.x out of concern for introducing incompatibilities in the middle of a release cycle. The installers for the 3.15 release cycle, now moving from alpha to beta phase, are currently using Tk 9.0.x. There are certainly advantages to using 9.0.x. The questions are: how much of a disruption would it be to current 3.14.x users to upgrade vs the benefits. And how to make that decision? To what extent are Tk 8.6.x vs 9.0 differences visible to tkinter users, both in code and in results? Not necessarily easy questions to answer. Opinions?
maj113 commentedon May 4, 2026
Well it's a bit hard to gauge this without a build to test for regressions/visual changes etc, if a build of py3.14/13 with tk/TCL 9.x was made it would be much easier for us to actually check what breaks, what needs to be changed etc, I am happy to test this on my own project I don't think nuitka work with 3.15 so I can't test that route yet
ThingamabobsCoding commentedon May 4, 2026
While I'm confident I could make you a list with to what extent Tk 9.0 will be visible to tkinter users, since all we need to get started is the pre-built tcl interpreter. The most important reason to backport sooner is for mac, since applications already break (widgets aren't rendered, windows just don't show up etc.) and even worse they can't be distributed with tk 8.6. - So you can't break whats already be broken. In addition, since tkinter just is a thin wrapper around the tk package there is not much of a change, rather there are a lot of add-ons, new features and fixes. Just tcl-user-scripts would (IIRC) break, but that's something you can't prevent anyways as long as you don't plan to retire tkinter with 8.6
For me personally I'll wait for a windows installer and would be more than happy if this year is the year, tkinter finally will makes it into the first stable release of 3.15. But the radio-silence on this issue made me wonder if nobody is actually working on it. Like I said I'm watching the progress since 2021 and even this issue is from 2024. Is there any light to this tunnel ?
ajkessel commentedon May 4, 2026
I would certainly appreciate a Tk 9 backport option if only to solve the issue of being able to submit apps built with pyinstaller to the App Store.
aivarannamaa commentedon May 5, 2026
Is it also the case for Windows? The changelog mentions the update for macOS installer, but not for Windows.
ned-deily commentedon May 5, 2026
In this context
installersmeantpython.org installers for macOS.Perhaps @zooba, @zware, and/or @hugovk can say something about Tk with Python Windows builds.
hugovk commentedon May 5, 2026
Looks like it's still on 8.6.15:
cpython/PCbuild/tcltk.props
Line 5 in 5dd2161
#124449
maj113 commentedon May 5, 2026
Maybe we could get a CI with the latest non-prerelease Python builds with newer Tk/Tcl (than what is present in latest stable Py builds) so we can test stuff. Somewhat annoying to test with prerelease Python versions where other packages aren't ready yet/don't work with it etc
hugovk commentedon May 5, 2026
What do you mean by CI?
maj113 commentedon May 5, 2026
GitHub Actions or whatever other continuous integration is used to create a python build, kinda like how is done for JIT and tail call interpeter actions but instead it also publishes the built python release as an artiract
zware commentedon May 5, 2026
Still on 8.6.15 for now. I have added 9.0.3 to
cpython-source-deps, but ran into failures in the attempt to build the artifacts forcpython-bin-depsand haven't gotten back to it to diagnose and fix.ajkessel commentedon May 5, 2026
Note that NSWindowDidOrderOnScreenNotification, the App Store blocker, is still referenced in tk 9.0.3 source code, but it should not be included in the binary since it is disabled via
#if 0. There is a Tk ticket also discussing this issue.ned-deily commentedon May 6, 2026
With regard to Tk 9 and the Python 3.14 python.org installers for macOS, thanks for your comments.
TL;DR Here's a chance to test the latest Python 3.14 on macOS with Tk 9.0.3 but act fast!
From my own experience with running Python's test suite, I appreciate that the parts of Tk 9.0 that tkinter uses, and that we have tests for, seem to perform as well as or better, particularly on macOS 26 Tahoe, than Tk 8.6.17. That is thanks to the hard work of the Tk project and especially Marc Culler (@culler). As a result of the recent feedback here, I have now done some testing of the latest 3.14 with Tk 9.0.3 on macOS, running the portions of the Python test suite that exercise IDLE, tkinter, and, thus, Tk, testing that we have been doing with Python 3.15, the next feature release currently under development. I found no obvious problems using Tk 9 with 3.14, other than one test case which erroneously fails due to a typo in a backport of the test case (now fixed for the next 3.14 release). Be aware that there were a number of changes made over time in the tkinter module and the Python test suite to accomodate running with both Tk 8.6.x and 9.0.x; some of these differences might affect your tkinter code as well. A quick inspection of both branches suggests that all or nearly all of those changes in the current main (3.15) branch are also in the 3.14 branch. And, as mentioned earlier, we have been shipping Tk 9 with the macOS Python 3.15.0 alpha preview releases over the past months.
But the proof is in the testing. As a result of your feedback and with the approval of the 3.14 release manager (@hugovk), we are making available for download a test version of the 3.14.5 release candidate 1 macOS installer that uses Tk 9.0.3 instead of 8.6.17. The contents of this test installer is built from the same Python source tag (v3.14.0rc1) as the official installer released yesterday (2025-05-04). As you may know, we usually do not publish Python release candidates anymore but an exception was recently made for 3.14.5 due to the scope of some fixes for a regression (unrelated to tkinter or Tk). As such, the accelerated current plan is to release 3.14.5 in a few days.
That means that there is a small window of opportunity here: if there is sufficient positive feedback in the next few days prior to the release date, we might be able to convince the release manager to ship 3.14.5 final for macOS with Tk 9.0.3 despite the short exposure period. Otherwise, we can still work towards shipping Tk 9 with a future 3.14 release for macOS and, we hope, for Windows as well.
The test installer for macOS is available to download from here:
https://www.python.org/ftp/python/3.14.5/python-3.14.5rc1_tcltk_903-macos11.pkg
The download file can be checked with the built-in
opensslutility on macOS:and the installer is signed with the usual Python Software Foundation Apple Developer certificates.
Please leave any feedback here on this issue for now. Thanks and good luck!
culler commentedon May 6, 2026
Here is some information about the not-too-distant future of tkinter. The Tcl/Tk project has now (!) started maintaining an informational TIP (TIP 713) that contains the planned release schedule for Tcl and (usually) Tk. Some highlights are:
So, looking forward, the 9.1 series should probably be the choice for tkinter in Python 3.16. There won't be fundamental differences between 9.0 and 9.1 for macOS - just (hopefully) some added features for which Apple provides pretty good support (e.g. accessibilty and right-to-left languages).
culler commentedon May 6, 2026
While I am very appreciative of the shout-out from Ned, I would like to say that the key idea, as well as a near complete proof-of-concept implementation, for the change between Tk 8.6 and 9.0 on macOS was due to Christopher Chavez. That idea was to use the updateLayer method of the NSView class in place of its drawRect method. The former allows creating and drawing directly to a CGImage backing store for a window. This is a much better fit for the design of Tk and allowed many annoying and problematic race conditions to be eliminated.
gh-124111: Fix tclWin32Exe value in tcltk.props for Tcl 9 (GH-149441)
ajkessel commentedon May 6, 2026
Thanks for this! I did some quick testing with my app and everything works perfectly without any changes -- looks a little better on MacOS than with the old tcltk, performance is excellent.
maj113 commentedon May 6, 2026
Great to see some progress on this, patiently waiting for a Windows test build 😅
gh-124111: Only set TCLSH_NATIVE for AMD64/ARM64 (GH-149443)
zware commentedon May 7, 2026
PR GH-149477 has some test failures on Windows with Tcl/Tk 9.0.3 that could use some investigation. They look to me like they're probably test issues that we just need to work around, but I'd like someone more knowledgeable (@serhiy-storchaka or maybe @culler?) to confirm that before I do any working around. I especially want to confirm that there's not some build option that I've missed that would affect encodings like this.
The failures:
culler commentedon May 7, 2026
My initial guess is that those tests are verifying that Tcl is handling unicode in the specific quirky way that was used in 8.6. Since Tcl 9 handles unicode correctly those tests probably need to be updated. I would not be surprised if the old unicode interface was different for Windows and macOS. The appearance of the word "surrogate" is a big clue in support of this theory.
culler commentedon May 7, 2026
Here is what happens in python:
>>> print("\ud83d\udcbb") Traceback (most recent call last): File "<python-input-0>", line 1, in <module> print("\ud83d\udcbb") ~~~~~^^^^^^^^^^^^^^^^ UnicodeEncodeError: 'utf-8' codec can't encode characters in position 0-1: surrogates not allowedTcl 8.6 used a variant of the utf-8 encoding, called CESU-8, which encodes UTF-16 surrogates. I think this test is trying to make sure that Tcl 9 is doing that, which it isn't. An analogous error to the one above should be raised in Tcl 9.
oehhar commentedon May 8, 2026
Dear @zware: @culler called out to Tcl Unicode experts to confirm. @jan.nijtmans would be the right person and may second.
Here is my comment:
Tcl/Tk 9 switched from 16 to 32 bit Unicode internal representation.
In consequence, surrogate pairs are now illegal.
On the UTF-8 level, CESU-8 is now illegal.
Internally, UTF-8 is used with the exception, that the NULL Unicode value is represented by \uC080.
There is a whole new set of access functions which check, that no illegal codes are entering the internals. Those access functions also do the \u0000->\uC080 transformation.
Practically, this means that surrogate pairs should be replaced by their 32 bit counterpart.
In addition to that, the ICU library is now used to find glyphes from Unicode Codepoints. Rendering of Upper Plane and Left to Right font handling is highly improved.
I am sorry to underline, that competent answers are better found when asking on Tk fossil: https://core.tcl-lang.org/tk
Please come back in case of any questions. Take care,
Harald
fixup! pythongh-124111: Update Windows to use Tcl/Tk 9.0.3
fixup! fixup! pythongh-124111: Update Windows to use Tcl/Tk 9.0.3
[3.14] gh-124111: Update macOS installer to use Tcl/Tk 9.0.3. (#149463)
hugovk commentedon May 10, 2026
The macOS installer now uses Tcl/Tk 9.0.3 in the newly release Python 3.14.5:
https://blog.python.org/2026/05/python-3145-is-out/
Thanks @ned-deily, and everyone for testing!
pythongh-124111: Update Windows to use Tcl/Tk 9.0.3
pythongh-124111: Update Windows to use Tcl/Tk 9.0.3
fixup! pythongh-124111: Update Windows to use Tcl/Tk 9.0.3
fixup! pythongh-124111: Update Windows to use Tcl/Tk 9.0.3
fixup! pythongh-124111: Update Windows to use Tcl/Tk 9.0.3
gh-124111: Update Windows build to use Tcl/Tk 9.0.3 (GH-149477)
[3.15] gh-124111: Update Windows build to use Tcl/Tk 9.0.3 (GH-149842)
gh-124111: Keep tests passing for Tcl prior to 9.0 (GH-150102)
[3.15] gh-124111: Keep tests passing for Tcl prior to 9.0 (GH-150102)
aivarannamaa commentedon May 21, 2026
I see that Tk 9.0.3 came to the Windows build of Python 3.15, thank you!
Can we get it in the next Windows builds of Python 3.14 as well?
zware commentedon May 21, 2026
We do expect to backport the Windows update 3.14 for parity with macOS, but we would like to have some more testing on the 3.15 pre-releases first. I've gone ahead and opened the backport PR as a draft to make it easier for interested parties to build their own, but it's not going to be merged quite yet.
[3.13] gh-124111: Update macOS installer to use Tcl/Tk 8.6.18. (#151125)
ajkessel commentedon Jun 16, 2026
The one obstacle I'm hitting with Tk 9.x is transparency support on MacOS. Tk has changed how it interacts with the MacOS window manager such that it may be impossible to have widgets with rounded edges without ugly borders outside the rounded edges.
For example, here is a screenshot of a tooltip demo from Custom2kinter (a recent fork of customtkinter) on Tk 8.6:
The same demo on Tk 9.0:
I've been banging my head against the wall trying to an elegant solution but it seems there may be none on the Python side. Wondering if anyone else on this issue looking to move to Tk 9.x has discovered this and, if so, if there are any workarounds/fixes.
culler commentedon Jun 16, 2026
The place to start is by running the widget demo called "Window styles for macOS.
There are several layers here. Tk 8.6 used Carbon features to control window styles. The commands to do that were in the ::tk::unsupported:: namespace. Tk 9.0 preserved the Carbon based command ::tk::unsupported::MacWindowStyle but also added a supported command
wm attriributes -stylemaskcommand which provides access to all of the [NSWindow styleMask] bits. It is possible that tkinter is still using the unsupported commands (which will disappear in 9.1) but tkinter provides access to the stylemask through the wm_attributes method. This is not perfect, but as a start you could try something like:That produces:
I am not sure that docmodal is what you want, however. It has other features, which you may or may not want, such as being an NSPanel rather than an NSWindow and always being topmost.
If you provide a stylemask which does not include 'titled' you will get square corners, which is what I would use for a tooltip, but apparentlly not what you want. Another option is
For me this gives:
The fullsizecontent bit is heavily used by Apple these days -- it gives a window whose titlebar is part of the background of the window, rather than having a separator line. (Safari is an example.) A window with fullsizecontent set can be dragged with the mouse by its title bar, even though the title bar blends into the background.
You can read the Apple documentation for [NSWindow styleMask] for more information.
culler commentedon Jun 16, 2026
Just to make sure that the white background in your image does not appear when the fullsizecontent window is on top of another Tk window, I put it on top of a flamingo-colored root window:
ajkessel commentedon Jun 16, 2026
Thanks @culler ! I'm trying to follow your example, but adding a
wm_attributesstylemaskdoes not have any visible effect for me in thecustomtkinter.run_showroom()demo. Here's the patch I applied. Am I approaching this the wrong way to apply a stylemask?culler commentedon Jun 16, 2026
What happens if you run my code in the terminal? Does it work?
It is possible that you need to wait for the window to be displayed or call update_idletasks, or both, before you can apply the stylemask.
This works for me if I run it as a python script, but it needs the update_idletasks:
ajkessel commentedon Jun 16, 2026
Figured it out--the problem was
toplevel.overrideredirect(True).This patch gives exactly the intended result in my testing on MacOS+Tk 9.0.
Just to clarify this comment--the fix we've found here will not disappear in 9.1, right? The fix should be durable?
culler commentedon Jun 16, 2026
Yes. It will work in 9.1 too. It does not involve any ::tk::unsupported commands. The
wm attributes -stylemaskcommand is supported by both 9.0 and 9.1. Also I just checked the _tkinter.c file in the Python 3.14.5 source code, and it does not use any unsupported commands.culler commentedon Jun 16, 2026
One comment about your patch. I thought you would need to include the "titled" bit as well as the "fullsizecontent" bit. Are you saying that is not needed?
ajkessel commentedon Jun 16, 2026
Oh, good catch. I was inconsistent: I had in one call but not the other. If I remove it from both, the tooltips are no longer rounded. If I include it in both, I get the desired effect. So
titleddoes seem to be necessary for this widget to behave in 9.0 the way it worked in 8.6.[3.13] gh-128846: Make tkinter tests robust against Tcl/Tk 9.0 (GH-15…
gh-124111: Update macOS installer to use Tcl/Tk 9.0.4. (#153868)
[3.14] gh-124111: Update macOS installer to use Tcl/Tk 9.0.4. (GH-153868
[3.15] gh-124111: Update macOS installer to use Tcl/Tk 9.0.4. (GH-153868
pythongh-124111: Update macOS installer to use Tcl/Tk 9.0.4. (python#…
pythongh-124111: Update Windows builds to Tcl/Tk 9.0.4
gh-124111: Update Windows builds to Tcl/Tk 9.0.4 (GH-153901)
[3.15] gh-124111: Update Windows builds to Tcl/Tk 9.0.4 (GH-153990)
[3.14] gh-124111: Update Windows build to use Tcl/Tk 9.0.4 (GH-150102) (
zware commentedon Aug 3, 2026
With 3.14+ updated to 9.0.4 on macOS and Windows, this is now complete. Thanks to everyone who contributed!
TheDemonGuard commentedon Aug 5, 2026
I installed 3.14.6 on Windows. However I am still getting TK version 8.6.
The command I used to confirm this is as follows
maj113 commentedon Aug 5, 2026
Most likely not yet published on the python website, the .6 was published on June 10th also looking at the tags .7 does not exist yet, might take a while
hugovk commentedon Aug 5, 2026
Python 3.14.7 will hopefully be released later today (5th August), after #153711 is fixed.
TheDemonGuard commentedon Aug 7, 2026
Thank you. I can confirm that Python 3.14.7 includes Tk 9.0.4 on Windows.
On MacOS, I confirmed that Python 3.14.6 includes Tk 9.0.4.