[issue46573] Python modules such as pyglet or pygame crash Python when tkinter message boxes are opened on MacOS.
Marc Culler added the comment: The TKApplication class is a subclass of NSApplication which adds both attributes and methods. Those are used throughout the macOS port of Tk, and as Ronald says, the unique instance of NSApplication in Tk is actually a TKApplication. Every macOS Application must have a unique NSApplication object which is referenced by the global variable NSApp. The TKApplication subclass was part of the first Cocoa port of Tk, long before I became involved, and it may have even been there in the Carbon days. Subclassing NSApplication appears to be something that Apple expects. I don't know enough about Categories to understand how they could be used to solve this problem. Do they somehow make it possible to add new methods and attributes to an existing NSApplication object at runtime? I have always thought of them as being syntactical in nature, as opposed to allowing runtime modifications of an object's class after the object has been instantiated. But I am not an expert on Categories by any means. - Marc On Wed, Feb 2, 2022 at 1:54 PM Ned Deily wrote: > > Ned Deily added the comment: > > Thanks for looking into this, Ronald. Before we close this as a Python > issue, perhaps Marc might have a suggestion on what should be done here > from a Tk perspective. > > -- > nosy: +culler > status: pending -> open > > ___ > Python tracker > <https://bugs.python.org/issue46573> > ___ > -- nosy: +Marc.Culler ___ Python tracker <https://bugs.python.org/issue46573> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44828] tkinter.filedialog linked with Tk 8.6.11 crashes on macOS 12 Monterey, breaking IDLE saves
Marc Culler added the comment: Well, not exactly ... culler@abner ~ % export SYSTEM_VERSION_COMPAT=1 culler@abner ~ % sw_vers ProductName:Mac OS X ProductVersion: 10.16 BuildVersion: 20G224 culler@abner ~ % export SYSTEM_VERSION_COMPAT=0 culler@abner ~ % sw_vers ProductName:macOS ProductVersion: 11.6.1 BuildVersion: 20G224 But that would only be helpful to me if the operatingSystemVersion property of an NSProcessInfo object also depended on that environment variable. Feel free to check the docs for an answer to that question: https://developer.apple.com/documentation/foundation/nsprocessinfo/1410906-operatingsystemversion -- ___ Python tracker <https://bugs.python.org/issue44828> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44828] tkinter.filedialog linked with Tk 8.6.11 crashes on macOS 12 Monterey, breaking IDLE saves
Marc Culler added the comment: According to wikipedia, it was only the Big Sur beta that identified itself as 10.16. (And I observed this with the beta). But the release and, I think, the later Big Sur betas stopped doing that. But I did eventually find a page showing a tweet that "documents" this behavior: https://eclecticlight.co/2020/07/21/big-sur-is-both-10-16-and-11-0-its-official/ I guess obscure tweets have replaced documentation. -- ___ Python tracker <https://bugs.python.org/issue44828> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44828] tkinter.filedialog linked with Tk 8.6.11 crashes on macOS 12 Monterey, breaking IDLE saves
Marc Culler added the comment: Where do you think that "feature" is documented? -- ___ Python tracker <https://bugs.python.org/issue44828> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44828] tkinter.filedialog linked with Tk 8.6.11 crashes on macOS 12 Monterey, breaking IDLE saves
Marc Culler added the comment: A (hypothetical) explanation: I think that each NSWindow maintains a queue of attached sheets. Failing to call the [parent endSheet] method left the file dialogue NSPanel in the queue, although it had been ordered offscreen and so was not visible. Opening the NSAlert added it to the top of the queue. Closing the alert caused it to be removed from the queue. But, since the queue was not empty, the window manager was supposed to orderFront the next sheet in the queue. That sheet was the file dialog, which had not been destroyed since adding it to the queue had incremented its reference count, and failing to remove it had not decremented its reference count. But the separate process that handles events for the file dialog had exited long ago. So that made the newly re-opened file dialog NSPanel into a zombie. -- ___ Python tracker <https://bugs.python.org/issue44828> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44828] tkinter.filedialog linked with Tk 8.6.11 crashes on macOS 12 Monterey, breaking IDLE saves
Marc Culler added the comment: OK. Shift-Command-S works. I will attach the fossil diff which should have enough context to indicate where to add the one new line. Then I will merge this change into the 8.6.12 release candidate -- Added file: https://bugs.python.org/file50420/endsheet.patch ___ Python tracker <https://bugs.python.org/issue44828> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44828] tkinter.filedialog linked with Tk 8.6.11 crashes on macOS 12 Monterey, breaking IDLE saves
Marc Culler added the comment: Yes that is what I meant. So I guess everything may be OK now. I did verify that the Tk demo can repeatedly open file save dialogs. When you press Command-S on a non-new edit window you do see the flash of the Save menu, so it would appear that a dialog was meant to appear, and there is no indication of why it did not. But that is an IDLE UX issue and in any case it sounds like Tk is not doing anything wrong. -- ___ Python tracker <https://bugs.python.org/issue44828> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44828] tkinter.filedialog linked with Tk 8.6.11 crashes on macOS 12 Monterey, breaking IDLE saves
Marc Culler added the comment: I found the cause of the zombie dialog window. I was supposed to call [parent endSheet] after calling [parent beginSheet]. Adding that stops the window from reappearing. But it does not solve the whole problem. Subsequent Command-S presses do not cause the file dialog to reappear. In fact, they do not even generate a call to showOpenSavePanel, which is supposed to present the dialog, and is also the function where all of the changes have been made. So this would seem to be a different bug. I see that if I open a new editor with Command-N and enter some text then Command-S works for the new editor. -- ___ Python tracker <https://bugs.python.org/issue44828> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44828] tkinter.filedialog linked with Tk 8.6.11 crashes on macOS 12 Monterey, breaking IDLE saves
Marc Culler added the comment: Heads up! A strange Apple quirk has been identified which could affect the file dialog behavior if the Tk library is compiled on macOS 10.XX and used on macOS 11 or 12. (I am not sure if this applies here.) The fix for the broken file dialog was to use different calls to display the dialog, depending on the OS version. The quirk is that code compiled on 10.XX and run on 11 or 12 will report the host OS version as 10.16 (which does not exist) no matter whether the actual version is 11 or 12. The simplest workaround is to replace the condition OSVersion < 11 by the condition OSVersion < 101600. Since tests like this occur in many places, a more robust workaround has been implemented in the Tk fossil repository and will appear in 8.6.12. -- ___ Python tracker <https://bugs.python.org/issue44828> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44828] tkinter.filedialog linked with Tk 8.6.11 crashes on macOS 12 Monterey, breaking IDLE saves
Marc Culler added the comment: That is great news! I will now merge the changes into the Tk core-8-6-branch and core-8-6-12-rc branches. -- ___ Python tracker <https://bugs.python.org/issue44828> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44828] tkinter.filedialog linked with Tk 8.6.11 crashes on macOS 12 Monterey, breaking IDLE saves
Marc Culler added the comment: Hi Ned. Here is one more attempt, hopefully the final one. I tested with IDLE on 10.14 (VM), 10.15(hard), 11(hard), 12(VM). I used Python 3.10.0. I replaced libtk8.6.dylib with the Tk lib compiled from the tip of the macosx_filedialog branch. I could not reproduce any of the issues that you reported. (But I hope you will retry as well, since just replacing the tkMacOSXDialog.c file in 8.6.11 is not the same as using the soon-to-be 8.6.12 release candidate.) I will attach the tkMacOSXDialog.c that I used. -- Added file: https://bugs.python.org/file50408/tkMacOSXDialog.c ___ Python tracker <https://bugs.python.org/issue44828> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44828] tkinter.filedialog linked with Tk 8.6.11 crashes on macOS 12 Monterey, breaking IDLE saves
Marc Culler added the comment: Hmmm, the 10.15 segfault seems to occur when writing the filename into the entry widget on the dialog. So maybe it is actually an issue with reference counting an NSString. I will have to look at that more carefully. -- ___ Python tracker <https://bugs.python.org/issue44828> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44828] tkinter.filedialog linked with Tk 8.6.11 crashes on macOS 12 Monterey, breaking IDLE saves
Marc Culler added the comment: Thanks for doing all the testing, Ned. I guess that the path forward is now clear. I will revert to the 8.6.11 code for 10.15 and earlier and use the new code for 11 and later. Of course the 8.6.11 code already has two cases, for 10.14 and earlier and 10.15 and later. So I will have some code cleanup to do. The UFO, by the way, was a standalone file dialog which was first being rendered as a separate window and then immediately attached to the parent window as a sheet. This was easier to see on a slower machine, like a VMWare VM which does not have graphics acceleration. Evidently the big change for 10.15 was that the file dialog was changed so that it became managed by a separate process, rather than just borrowing the current process's event queue. The reason, supposedly, was to make it so that an app running in a sandbox could still read and write the user's files. It seems that Apple had a hard time making this work, and the UFO as well as the assertion error suggest to me that they still haven't figured it out. So I thnk we can expect more trouble with the next OS. At least we have a year before that adventure starts. Needless to say, having some documentation from Apple would be much more pleasant than the trial and error method that we are forced to use now. But we know better than to expect that. -- ___ Python tracker <https://bugs.python.org/issue44828> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44828] tkinter.filedialog linked with Tk 8.6.11 crashes on macOS 12 Monterey, breaking IDLE saves
Marc Culler added the comment: Hi Ned, I think this problem is fixed now in the tip of the Tk macosx_filedialog branch. I am attaching the tkMacOSXDialog.c file from that branch. I think you should be able to just replace the version in 8.6.11 and be able to build a working version. I have tested on macOS 10.14, 10.15, 11 and 12. Can you please test on your systems? If it looks OK I will merge the changes into 8.6.12-rc so they will appear in the 8.6.12 release when that happens. It should be fairly soon. -- Added file: https://bugs.python.org/file50398/tkMacOSXDialog.c ___ Python tracker <https://bugs.python.org/issue44828> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44828] tkinter.filedialog linked with Tk 8.6.11 crashes on macOS 12 Monterey, breaking IDLE saves
Marc Culler added the comment: Thanks, Ned, for finding my mistake which you generously called a typo. I have fixed the inequality in the Tk fossil repository. Incidentally, there is now a core-8-6-12-rc branch of Tk, also containing the fix. So it should not be too long before 8.6.12 is released. I will look at the code and check whether I see the UFO that you report. As you know, all that Tk does is to open an NSOpenPanel. Once that is open it is completely handled by the OS. Tk sees no events from the modal interaction and does not have any way of controlling any aspect of the dialog. So the only hope would be that it is possible to set some configuration option before opening the NSOpenPanel which would somehow cause the OS to assign focus to the correct widget. I will try to investigate what options are available. -- ___ Python tracker <https://bugs.python.org/issue44828> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44828] Using tkinter.filedialog crashes on macOS Python 3.9.6
Marc Culler added the comment: No, Apple is not going to do away with their NSOpenPanel. There is always some churn when they release a new OS. Subtle changes to APIs can occur with no warning and no documentation. Sometimes they are bugs. Sometimes they disappear when the OS is released. Sometimes they are permanent. I would not recommend using a beta version of the OS to develop your tkinter app. -- ___ Python tracker <https://bugs.python.org/issue44828> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44828] Using tkinter.filedialog crashes on macOS Python 3.9.6
Marc Culler added the comment: Hi Ronald, There is no calendar scheduling for Tk releases. Don Porter decides when they happen. But I think we are due for another one soonish. In case it doesn't happen before the next Python release I will attach the patch file for commit a32262e9. (Note that this is subject to change - I still need to test on 10.14.) I believe that this patch is completely self-contained and can be applied to the 8.6.11 release. (Hint: Tk uses fossil as its SCM system. On a fossil timeline, clicking any two nodes generates their diff. The Tk timeline is at https://core.tcl-lang.org/tk/timeline) -- keywords: +patch Added file: https://bugs.python.org/file50343/openfile.patch ___ Python tracker <https://bugs.python.org/issue44828> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44828] Using tkinter.filedialog crashes on macOS Python 3.9.6
Marc Culler added the comment: I was able to fix this problem for Tk on Monterey beta [21A5543b]. The fix has been committed to the tip of the core-8-6-branch in the Tk fossil repository. Here is a synopsis. Tk used to open the file dialog by calling [NSApp runModalForWindow:panel]. Starting with the release of 10.14 this call would produce a warning message on stderr saying that [NSOpenPanel runModal] should be used instead. But on systems older than 10.14, the runModal method would fail because the completion handler would not get called. Now, with 12.0 (at least in the beta) calling [NSOpenPanel runModal] produces an error dialog saying "The open file operation failed to connect to the open and save panel service" and this would be accompanied by a traceback printed on stderr for an assertion error. (It was not a "crash" but the file selection would fail.) However, it turns out that calling [NSApp runModalForWindow:panel] no longer produces the warning in 12.0, and it works correctly. So my workaround was to add conditional code that only calls the runModal method on 10.14 and 10.15 and calls runModalForWindow on other versions of macOS. I tested on 10.15 and it works there as well. Needless to say, none of these changes are documented by Apple. -- ___ Python tracker <https://bugs.python.org/issue44828> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44828] Using tkinter.filedialog crashes on macOS Python 3.9.6
Marc Culler added the comment: Unfortunately, I am still seeing this failure in Monterey beta 9. However, we are no longer alone. Here is a report of the same issue in Android Studio: https://stackoverflow.com/questions/69068842/android-studio-open-file-operation-failed-the-open-file-operation-failed-to-co This is reportedly fixed in the Adroid Studio beta, so maybe someone will be able to figure out what Google did to workaround the problem. -- ___ Python tracker <https://bugs.python.org/issue44828> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44828] Using tkinter.filedialog crashes on macOS Python 3.9.6
Marc Culler added the comment: I should have mentioned that I tested on Intel hardware, not M1. I do not have access to an M1 Apple at this time. -- ___ Python tracker <https://bugs.python.org/issue44828> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44828] Using tkinter.filedialog crashes on macOS Python 3.9.6
Marc Culler added the comment: I built Tcl and Tk 8.6 on Monterey beta (21A5294g) and I see this traceback in the Wish file dialog demo. Note that this is *not* an error. The file dialog works fine. This is a non-fatal NSInternalInconsistencyException which prints a traceback to stderr. It occurs within a call to [NSSavePanel runModal] which is entirely Apple code. The runModal method is not deprecated. Most likely, when Apple releases Monterey the assert command will have been removed, possibly replaced by a call to NSLog which writes information into a log file rather than print it to stderr. (NSLog itself prints to stderr when debugging is enabled.) Of course macOS apps run without stderr, so you will only see this traceback when running a python program from the terminal. (Any linux user who runs linux apps from the terminal is used to seeing lots of stderr messages in stderr. Try running okular from a terminal sometime. So we shouldn't complain too much.) Anyway, this looks harmless and the messages will almost surely go away in the production version. However, there are several new deprecations related to specifying preferred file types in a file dialog which I will address in Tk before Monterey is released. Beta releases are betas, even for macOS. - Marc On Thu, Aug 5, 2021 at 1:23 PM Ned Deily wrote: > > > Ned Deily added the comment: > > > I used brew.sh to install Python, which I think uses the universal installer > > As far as I know, Homebrew builds its own Python and Tk. > > > After I reinstall macOS, if you need further testing, i’m open to trying. > > Thanks. I think the next step would be to try to reproduce just using Tcl and > Tk as this most likely is an issue in Tk rather than Python. It's also quite > possible that the underlying problem will be fixed in a future Monterey beta. > Alas, I don't have time to look further into this in the immediate future. > Perhaps someone can follow up directly with the Tk folks. > > -- > nosy: +culler > > ___ > Python tracker > <https://bugs.python.org/issue44828> > ___ -- nosy: +Marc.Culler ___ Python tracker <https://bugs.python.org/issue44828> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42541] Tkinter colours wrong on MacOS universal2
Marc Culler added the comment: Well, actually the release was announced today. There was one bug fix which did not make it into the release but could possibly affect Python, due to the fact that Python is installed as a framework, and frameworks to not have icons. I can supply a (1-line) patch if needed. To test, import tkinter, create a tkinter.Tk object and open the "About Python" menu. If the icon displayed on the About dialog looks like a folder then you need the patch. Please let me know what happens when switching to dark mode. My concern arises from my understanding that python is being built with a macOS 10.9 SDK, which does not understand dark mode. I don't know what will happen when running that code on a system which does support dark mode. Since Tk can be build on Big Sur with a minimum target of 10.9 (and I recommend doing so) I think it should be OK. There may be warnings when linking _tkinter.so though. I do not understand why the 10.9 SDK is needed, since I recently built Python 3.9.0 on Big Sur, with a minimum target of 10.9, and did not see any significant issues. (Well, maybe A few warnings from the posix module need investigation.) -- ___ Python tracker <https://bugs.python.org/issue42541> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42068] For macOS, package the included Tcl and Tk frameworks in a rational way.
Marc Culler added the comment: Hi Ned, I have a comment about the code signing issues that would arise if the Tcl and Tk frameworks were embedded as actual subframeworks inside the Python.framework, and a user later replaced those with newer versions. The answer is that no new issues arise. The current Python.framework fails codesign verification as soon as a single new package is installed with pip (even upgrading pip itself). The codesign command detects the new files and exits with non-zero status if called with --verify. In verbose mode it will list all of the files that were added. This does not prevent python from working. So it should just be acknowledged that python's codesigning is used purely to make installation simpler and that no attempt is currently being made to ensure that an installed python framework continues to pass codesign verification. As a consequence, my proposal in this ticket would raise no new codesigning issues, but it would allow users to much more easily upgrade the Tcl and Tk embedded in /Library/Frameworks/Python.framework versions. It would also simplify the recipe for building Tcl and Tk in the buildscript. While the python framework may be viewed as a black box, in fact it is not a black box at all. It can be changed at will either by python itself or by a user. Making its structure clearer and cleaner could only be an improvement. -- ___ Python tracker <https://bugs.python.org/issue42068> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42541] Tkinter colours wrong on MacOS universal2
Marc Culler added the comment: Yes, I can provide a good commit ID to work with. Please give me a couple of days. The current tip is almost an ideal choice. There have been no Aqua bug reports for quite some time. But now there is one new one (from Kevin) so I'd like to fix that, discuss with Kevin, and test. -- ___ Python tracker <https://bugs.python.org/issue42541> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42068] For macOS, package the included Tcl and Tk frameworks in a rational way.
Marc Culler added the comment: Ned - do you have any news on the topic of packaging Tcl/Tk within the Python bundle? -- ___ Python tracker <https://bugs.python.org/issue42068> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42068] For macOS, package the included Tcl and Tk frameworks in a rational way.
Marc Culler added the comment: Dear Ronald, You are correct that "It is already possible to replace the Tcl/Tk libraries by replacing the relevant files in Python.framework." I know that because I have done it. Moreover, having done it, I know that it is much more difficult than it should be. A large part of the difficulty is that the directory structure of the Tcl/Tk installation within the Python framework is undocumented and completely different from that used within Tcl.framework and Tk.framework. There is no need for that. The versions of those frameworks with Python wants to use could simply be embedded within the Python.framework as subframeworks. That simplifies the build and it simplifies upgrades and it costs nothing as far as Python is concerned. The backwards compatibility promise offered by Tk and Tcl means that replacing Tcl/Tk 8.6.X with Tcl/Tk 8.6.Y will work with no change to the binary _tkinter. module. When improvements or bug fixes are made to Tcl and Tk it should be straightforward for users to update Python so that it will take advantage of those improvements. Before Tcl and Tk were included in the Python framework that was simple. You could just install the newer release of Tcl/Tk (at least for patch releases). Since _tkinter would look in the standard places, i.e. /Library/Frameworks/Tk.framework (or Tcl.framework) for its shared libraries, that would automatically work. The point is that it could, and should, be just as simple to make such an upgrade with the new where Tcl and Tk are included within the Python.framework. That is what I am trying to accomplish. The scope of this change will probably be clearer if I make a pull request. So I will do that. -- ___ Python tracker <https://bugs.python.org/issue42068> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42068] For macOS, package the included Tcl and Tk frameworks in a rational way.
Marc Culler added the comment: Dear Eric, I am aware that python is cross platform. The change that I am proposing would be almost entirely limited to the file: Mac/BuildScript/build-installer.py which is entirely mac-specific. It controls how the Mac installer is constructed. Specifically, the effect would be to change the directory structure of the Python framework which is installed by the Python installer package in /Library/Frameworks/Python.framework. There presumably would also be a very small change in the _tkinter module to account for the fact that the Tcl and Tk shared libraries would acquire new pathnames. My sincere apologies for offending you by my use of the words "crazy" and "random noise". I hope you will be able to focus on the content of the ticket in spite of my use of those offensive words. -- ___ Python tracker <https://bugs.python.org/issue42068> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42068] For macOS, package the included Tcl and Tk frameworks in a rational way.
New submission from Marc Culler : Packaging Tcl and Tk within the python framework is a great idea and a big improvement. But the way it is being done is pretty crazy, and makes it unnecessarily difficult to upgrade the version of Tcl/Tk that python is using. That is something which should be easy, especially since python is still using version 8.6.8 even though 8.6.11 is about to be released and includes the results of a huge effort to improve and stabilize the macOS port of Tk. There is a standard and completely straightforward way of including a framework within a framework. The normal thing to do would be to create a directory Python.framework/Versions/X.Y/Frameworks/ which contains Tcl.framework and Tk.framework. Upgrading to a newer version of Tcl and Tk would then simply require updating those frameworks, which would be very easy to accomplish, for example, with a .pkg file. Instead of doing this, Python currently jams everything related to Tcl and Tk into its lib directory, changing the library and directory names randomly and breaking the standard directory structure that Tcl and Tk use in their frameworks. Why not make it standard and simple? Why add all of this random noise? -- components: macOS messages: 378860 nosy: culler, ned.deily, ronaldoussoren priority: normal severity: normal status: open title: For macOS, package the included Tcl and Tk frameworks in a rational way. type: enhancement versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue42068> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38882] IDLE should not make the about dialog be a transient of the withdrawn root window
Marc Culler added the comment: One thing to keep in mind is that Apple's release of OSX 10.14.6 caused Tk 8.6.8 to stop working on many systems in an extremely obnoxious way. Starting a Tk Application would trigger a segfault in Apple's WindowServer which would then cause the user to be immediately logged out. That does not happen with 8.6.10. (Other types of applications were also affected.) Here is one of many bug reports: https://github.com/matplotlib/matplotlib/issues/14999 Whether the crash would occur depended on which Apple hardware was used. -- ___ Python tracker <https://bugs.python.org/issue38882> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38882] IDLE should not make the about dialog be a transient of the withdrawn root window
Change by Marc Culler : -- versions: +Python 2.7 -Python 3.7 ___ Python tracker <https://bugs.python.org/issue38882> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38882] IDLE should not make the about dialog be a transient of the withdrawn root window
Marc Culler added the comment: I should have mentioned that I did not see the IDLE hang with Python 3, only with Python 2.7. So I changed the Version in the ticket. -- versions: +Python 3.7 -Python 3.8 ___ Python tracker <https://bugs.python.org/issue38882> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38882] IDLE should not make the about dialog be a transient of the withdrawn root window
Marc Culler added the comment: It definitely makes sense for an on-screen window to have a transient dialog. With a little care (see "messages boxes" in the widget demo) on the mac the transient can be a "sheet" that opens from the top of the master window. It even makes sense for an iconified window to have a transient since the window manager still controls iconified windows. But a withdrawn window, with no icon (and no listing in the mac Window menu) is beyond the user's control. The really deadly combination is when a transient of a withdrawn window (so the transient is withdrawn) also has a grab on mouse and keyboard events. That one should be avoided. It is not clear to me why Tk allows it. I believe it should be avoided on all platforms, since withdrawn windows are supposed to be completely removed from the window manager and only known to Tk. But testing is needed, of course. I don't know the full history. I know there were changes between 8.6.9 and 8.6.10 needed to bring the mac port to its current state where it passes all of the Tk regression tests. (That is not the case with unix at the moment and I know there are many issues with iconified and withdrawn windows in Gnome 3 due to changes in window manager behavior which have not been fully incorporated into Tk.) I suspect there were many prior releases with no changes to this behavior on the mac. PS The formerly soon-to-be-released 8.6.10 has now been released. -- ___ Python tracker <https://bugs.python.org/issue38882> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38882] IDLE should not make the about dialog be a transient of the withdrawn root window
New submission from Marc Culler : The soon-to-be-released Tcl/Tk 8.6.10 includes some changes to the macOS port which cause the wm transient command to behave in the way that the Tk manual says it should: "A transient window will mirror state changes in the master and inherit the state of the master when initially mapped." This means that a transient of a withdrawn window will be withdrawn. In the macOS version of IDLE the about dialog is assigned as a transient of the root window which is withdrawn, so the dialog does not appear on the screen. Consequently, activating the about menu will cause IDLE to become unresponsive as it waits for an offscreen window to be closed. Deleting line 28 in aboutDialog.py: self.transient(parent) makes the about dialog behave normally. -- assignee: terry.reedy components: IDLE messages: 357195 nosy: culler, terry.reedy priority: normal severity: normal status: open title: IDLE should not make the about dialog be a transient of the withdrawn root window type: behavior versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue38882> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32931] Python 3.70b1 specifies non-existent compiler gcc++
New submission from Marc Culler <cul...@math.uic.edu>: Compiling an external module in the 3.7.0b1 prerelease on macOS High Sierra failed for me because a compiler named "gcc++" was not found. As far as I can tell there is no such compiler in the current XCode release. I don't know if there ever was one. The culprit file is: /Library/Frameworks/Python.framework//Versions/3.7/lib/python3.7/_sysconfigdata_m_darwin_darwin.py The following patch fixed the problem for me: 38c38 < 'CXX': 'gcc++', --- > 'CXX': 'g++', 484c484 < 'LDCXXSHARED': 'gcc++ -bundle -undefined dynamic_lookup', --- > 'LDCXXSHARED': 'g++ -bundle -undefined dynamic_lookup', -- components: macOS messages: 312697 nosy: culler, ned.deily, ronaldoussoren priority: normal severity: normal status: open title: Python 3.70b1 specifies non-existent compiler gcc++ versions: Python 3.7 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32931> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30310] tkFont.py assumes that all font families are encoded as ascii in Python 2.7
Marc Culler added the comment:
The name of a Tk font family is a byte sequence obtained from the operating
system. But, this being Python 2.7, there is no distinction between the str
type and the bytes type. The byte sequence is definitely not ascii encoded on
a Japanese Windows system. It is a utf8-encoded byte string. This is why I
called v.decode('utf8') in my patch. Note that this bug does not occur with
Python 3.6.
Terry, I understand that text is better and I hope I never have to resort to an
image again. Since I don't speak Japanese myself, even setting up a Japanese
Windows VM for testing was pretty challenging for me. I was able to take a
screenshot without having to translate any Japanese menus, so I took that
shortcut. Sorry about that.
This report was indeed triggered by a real "crash" in your sense. It occurred
in a GUI application bundled with pyinstaller. Any unhandled exception in a
pyinstaller app results in termination of the process and posts a Windows error
message box saying 'Failed to execute script XXX'. For the report, however, I
was isolating the underlying unhandled exception in Font.copy() that had caused
the real crash of the GUI application.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30310>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30310] tkFont.py assumes that all font families are encoded as ascii in Python 2.7
Marc Culler added the comment: The attached patch simply decodes string options to the Font._set() method using the utf8 codec. Other options (which will be numbers) are converted to ascii strings as currently happens. This makes it possible to use the Font.copy() method without raising an exception when the font family name is not ascii encoded. -- keywords: +patch Added file: http://bugs.python.org/file46855/tkFont.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30310> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30310] tkFont.py assumes that all font families are encoded as ascii in Python 2.7
Changes by Marc Culler <cul...@math.uic.edu>: Added file: http://bugs.python.org/file46851/JapanesePythonBug.png ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30310> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30310] tkFont.py assumes that all font families are encoded as ascii in Python 2.7
New submission from Marc Culler:
And that is a very bad assumption. On Windows 10 in the Japanese locale the
default TkFixedFont has family u'\uff2d\uff33 \u30b4\u30b7\u30c3\u30af' (a
transliteration of MS Gothic).
The error occurs on line 51:
47 def _set(self, kw):
48 options = []
49 for k, v in kw.items():
50 options.append("-"+k)
>>>> 51 options.append(str(v))
52 return tuple(options)
I will attach a screenshot showing the crash on a Japanese Windows 10 system,
running in the Python 2.7 command line application.
--
components: Tkinter
messages: 293256
nosy: culler
priority: normal
severity: normal
status: open
title: tkFont.py assumes that all font families are encoded as ascii in Python
2.7
type: crash
versions: Python 2.7
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30310>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29605] Python2.7-32 misreports architecture on macOS.
New submission from Marc Culler: On macOS, the 32 bit python 2.7 reports its architecture as '64bit' in platform.architecture(). Note that the 32 bit Python versions 3.4, 3.5 and 3.6 all correctly report '32bit'. $ python-32 Python 2.7.13 (v2.7.13:a06454b1afa1, Dec 17 2016, 12:39:47) [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import platform >>> platform.architecture()[0] '64bit' >>> import sys >>> sys.maxsize > 2**32 False -- components: macOS messages: 288200 nosy: culler, ned.deily, ronaldoussoren priority: normal severity: normal status: open title: Python2.7-32 misreports architecture on macOS. versions: Python 2.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29605> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28440] pip failures on macOS Sierra
New submission from Marc Culler: Changes made to /Library/Python on macOSX Sierra cause the --with-ensurepip compiler flag to fail, and lead to failures of pip after installing Python. The new file that causes the problem on Sierra is: /Library/Python/2.7/site-packages/Extras.pth The current version of site.py reads that .pth file, which results in sys.path containing the path: /System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python The latter directory (which is protected by SIP) contains many Python 2.7 packages, including easy_install, setuptools, six, py2app, numpy, pylab and pyOpenSSL. The effect of including this SIP-protected path in sys.path is this: installing or upgrade a package in /Library/Frameworks/Python.framework which is also installed as an "Extra" in the /System/Frameworks/Python.framework will cause pip to attempt to delete the "old" package from its SIP-protected directory, leading to a "Permission Denied" exception and a failed install. Given that Apple has now tied /Library/Python to the system Python in this way, thereby making a separate Python framework in /Library/Frameworks unusable, the natural solution to this problem would be to stop including any /Library/Python paths in sys.path. I am attaching a patch that removes the block of code in site.py which adds these paths. -- files: pipfails.patch keywords: patch messages: 278649 nosy: Marc.Culler priority: normal severity: normal status: open title: pip failures on macOS Sierra type: compile error Added file: http://bugs.python.org/file45090/pipfails.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28440> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10731] UnicodeDecodeError in OS X tkinter when binding to MouseWheel
Marc Culler added the comment: Thanks, Ned! It seems to be completely fixed by 8.5.12. -- nosy: +Marc.Culler ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10731 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10731] UnicodeDecodeError in OS X tkinter when binding to MouseWheel
Marc Culler cul...@math.uic.edu added the comment: I am running OSX 10.5.8 on this macbook. The Tcl/Tk package on the system is ActiveState Tcl/Tk 8.4.19. I just installed Python 3.2 (r32:88452, Feb 20 2011, 10:19:59) from http://www.python.org/getit/releases/3.2/ and I am still seeing this bug. It does not occur with the Python 2.7 Tkinter package, which uses the same Tcl/Tk framework. So if it is a bug in Tk, it is harmless when used with Python 2.7. But, after all, it is not so surprising to see new UnicodeDecodeErrors when porting from Python 2 to Python 3. -- versions: +Python 3.2 -Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10731 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10731] UnicodeDecodeError in OS X tkinter when binding to MouseWheel
New submission from Marc Culler cul...@math.uic.edu:
In OS X tkinter the two-finger scroll generates MouseWheel events.
The following code:
bug.py
import tkinter
def mouse_wheel(event):
print('Mouse wheel event')
tk = tkinter.Tk()
list = tkinter.Listbox(tk)
list.bind('MouseWheel', mouse_wheel)
for n in range(20):
list.insert(tkinter.END, str(n**n))
list.pack(fill=tkinter.BOTH, expand=1)
tk.mainloop()
often throws a UnicodeDecodeError exception with a traceback like the one shown
below when you do a two-finger scroll in the window.
Traceback (most recent call last):
File bug.py, line 12, in module
tk.mainloop()
File
/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/tkinter/__init__.py,
line 1009, in mainloop
self.tk.mainloop(n)
UnicodeDecodeError: 'utf8' codec can't decode byte 0x84 in position 1:
unexpected code byte
The value of the byte changes from time to time, and sometimes it may be
possible to scroll a few times without producing the error.
This problem did not occur on my Mandriva 2010.2 system. I think it is
specific to the Macintosh. It might possibly be related to:
http://bugs.python.org/issue834351
--
components: Tkinter
messages: 124287
nosy: culler
priority: normal
severity: normal
status: open
title: UnicodeDecodeError in OS X tkinter when binding to MouseWheel
type: crash
versions: Python 3.1
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10731
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6124] Tkinter should support the OS X zoom button
New submission from Marc Culler cul...@math.uic.edu: As far as I can tell, no Tkinter event or pseudo event is generated by clicking the green zoom button on Mac OS X windows. This makes it impossible to support that OS X paradigm in a Tkinter application. I would like to be able to bind Zoom to a command that resizes the window according to the OS X UI guidelines. By the way, the guidelines specify that the interpretation of zoom depends on the application, and the effect need not be the same as maximize. -- components: Tkinter messages: 88419 nosy: culler severity: normal status: open title: Tkinter should support the OS X zoom button type: feature request ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6124 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6015] Tkinter Scrollbar in OS X 10.5
Marc Culler cul...@math.uic.edu added the comment: I have the same issues with Python 2.6 code I have written. In OS X 10.4 the scrollbars work correctly with a Tkinter Text widget. The same code running in 10.5 exhibits this erratic behavior. It appears as though mouse movement events are queued up, causing the mouse to get ahead of the scrollbar. Later, at some random time, it appears as though the queued events get processed all at once, causing the scrollbar to leap ahead of the mouse. The scrollbar widget display also becomes corrupted at times, with the blue color from the slider being written into the buttons at the bottom. -- components: +Tkinter -IDLE nosy: +culler title: Scrollbar in Idle os x 10.5 - Tkinter Scrollbar in OS X 10.5 type: - performance versions: +Python 2.6 -Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6015 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
