-
-
Notifications
You must be signed in to change notification settings - Fork 31k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
In Idle, Mac tabs make editor status line disappear. #79045
Comments
Mac now puts multiple tabs inside of application window instead of starting a separate window (with some OS settings). With just one file being edited in Idle (no tab line) the bottom line with the numerical cursor coordinates is visible. When there are multiple tabs (and the tabbing heading therefore) the bottom cursor coordinates are missing. |
I do not see this 64-bit 3.7.1rc1 (see bpo-34863) on 10.13.6 with, I believe, default settings. Are you reporting multiple tabs as a bug, or a feature resulting from intentional settings? If the latter, this may be something the tcl/tk does not support properly. Ned and Tal, do either of you know anything about this? In any case, is the status bar missing, or is the cursor position missing from the status bar. |
This appears to be a system settings option in Mac OS Sierra set under the Dr. Andrew N. Harrington On Mon, Oct 1, 2018 at 9:30 PM Terry J. Reedy <report@bugs.python.org>
|
Confirmed on macOS High Sierra 10.13.6, with "Prefer tabs when opening documents" set to "Always". See attached screenshot with the macOS tabs; indeed the bottom bar is missing. |
Interesting! I was not familiar with that system preference nor that it would just (sort of) work in IDLE; I'm presuming that there is nothing in IDLE that knows about this. I'm not sure whether Tk gets that behavior for free (because of the use of an underlying macOS API) or whether it is intended to be supported behavior. Or what would need to be done in IDLE to fully support it. Perhaps Kevin might be able to give some guidance from the Tk perspective. Ah, I see that if the selected tab is an edit window rather than the IDLE shell window and then one uses the cursor to resize the window (grabbing the bottom right hand corner), the cursor location info reappears and then seems to behave as expected: disappears when selecting the shell tab and reappears when selecting the edit tab. Further, when opening yet edit window, the cursor info is missing on the new edit tab but still present on the previous edit tab; resizing the window again causes the cursor info to now appear in the newly edit tab. So all of this seems to be IDLE-specific. |
One more time: "Further, when opening yet edit window" should be "Further, when opening yet another edit tab (in the same IDLE window)" |
Optionally converting windows to tabs is an over-arching goal for IDLE. To do it with IDLE code, IDLE must create a frame (and keep a reference) but not a toplevel. I presume that the Mac window manager extracts the window title and frame from the window, discards the window, and puts the title and frame on a tab. Kevin, does tcl/tk know about or cooperate with this conversion? IDLE's default editor size is configured as 40 lines of 80 characters. On my MacBook Air, the windows are actually 38 lines; that is all that fits between the title bar and taskbar. Additional windows overlap, but are moved to the right. If I set the window height to less than 38, say 30, the initial window does not fill the vertical space, showing some of the background beneath. Additional windows appear a bit down as well as to the right. I found the setting under System Preferences Dock and more or less confirm Ned's report. It appears that the status bar is hidden rather than deleted. I set the initial window size to 36, 2 lines less than the actual maximum, hoping the status bar would remain in a larger window after opening a second window. No such luck. The size remains 36, with the bar hidden. For the editor windows, grabbing the vertical resize made the status appear and stay. For Shell, it disappeared either immediately or when tabbing away and back. Since Shell subclasses EditorWindow, I don't know why the difference. The resolution to this issue from IDLE's viewpoint should be a new IDLE doc subsection 'IDLE on MacOS', probably under 'Help and Preferences'. It would explain differences from IDLE on Linux and Windows. Besides this issue, there is the single title bar, menu differences, and zoom behavior (horizontal expansion as well as vertical). Also, as far as I can tell so far (and someone correct me if this is wrong), only 1 instance of IDLE can run (for a given binary, at least), which means only 1 Shell. (On Windows, I can run multiple instances of a given binary, and I presume the same is true on non-Mac *nix.) |
The behavior outlined in the screenshot is, I believe, a component of the native Cocoa window that underlies Tk; it cannot be controlled or accessed from Tk. It's probably better to avoid altogether or re-implement somehow in IDLE. |
The search and replace dialogs are also broken by "Prefer tabs when opening documents" being active: they as separate tabs rather than a dialog window. |
As part of revising the IDLE Docs, I want to add a section for running on MacOS (issue in preparation, section title undecided). I already planned on mentioning this setting. It seems it should be dis-recommended, at least at present. |
I agree that mentioning that IDLE won't work 100% with that setting on is a good idea. I also agree that at this point it's not worth the effort to do anything more than that. |
Terry, FYI, according to Apple, the correct current styling for the Mac Operating System is "macOS". We should be using that spelling in the documentation. |
OK, I will change doc references in the next doc patch, or maybe in a patch that also changes module macosx to macos. (I want to keep it all lowercase. |
I don’t think it’s worth changing the file name or other names, that just causes needless churn and the possibility for stranded files on an upgrade. I’d just update the docs and messages. |
Can we detect whether this system preference is enabled? If so, perhaps |
See PR #54673, which warns if "Prefer tabs when opening documents" is set to "Always". |
I will leave macosx alone at least until after 3.6.8. But I plan to merge some modules and want to be able to rename others. bpo-33906 changed windows.py to window.py for 3.7.1 (and 3.6.7). The 3.7.1 Windows installer deleted windows.py; the macOS installer did not. Tal, do you have a Linux 3.7.1 upgrade of 3.7.0? What is the downside of the old, dead version? I could, for the maintenance version, add back a file containing |
By default, macOS installers just install the files included in a package. For macOS Python installer packages, the problem arises if a particular file is deleted or renamed in a maintenance release and a user has already installed an earlier version of that release family. It's possible for a post-install script to be added to the macOS installer to deal with particular files but that doesn't happen automatically. On Linux and other OSes, it would depend how the third-party distributor's packaging system works; some would detect a changed or missing file name, some likely wouldn't. And there's always the possibility that third-party packages or users are using or modifying standard library files. It's just best to avoid the problem altogether unless there is some really compelling reason. Of course renames or deletes for the initial release of a feature branch (e.g. 3.8.0) generally aren't a problem. |
See bpo-35213 for 'macOS' changes. |
Changing only master could make backports difficult to impractical. (Pure module name changes would be an exception if gits keep track of them and reverses them for a backport.) If a module is touched, user changes to that module get wiped out when the module is replaced. Aside from that, most of idlelib was declared private and 'subject to change' to allow refactoring. The only problem I have heard about is that 3.6 broke IDLEX (as I expected). IDLEX which made changes far beyond the narrow extension protocol. Roger solved that by incorporating a private copy of 3.5 IDLE with whatever modifications he wants. This is exactly what Nick said people should do, in the 3.6 alpha discussion, if they wanted frozen IDLE. |
FWIW: I did a quick check of the 3.7.2rc1 IDLE, that now has Tk 8.6.9.1, with the "prefer tabs" setting on. The newly added check in IDLE does work as designed but it also looked like the original problem has been fixed in Tk, that is, the co-ordinates did seem to show up in the tabs. It's probably fine to leave things as they are but I mention it in case anyone wants to revisit this :) |
PR 6665, for bpo-33397 (add font resizing to text view and help viewer) got listed because I discovered that increasing and decreasing font size with control wheel/+/- can cause the [close] button to disappear and reappear. (I hope to use FontSizer for editor texts as well, and don't want it to affect the status bar.) I speculated that there might be some connection to this issue. |
Ned, the warning is non-specific as to what might go wrong. I would not want to remove it until I had tested everything possibly relevant with tabbing set. And there is still the possibility that people will run IDLE with earlier tk releases. The bpo-33397 issue of the close button disappearing was solved by packing the close button first. In the editor, the status bar is already packed into the ListedTopLevel first, before the text frame (perhaps for the same reason). |
FTR, Raymond reports in a tweet (https://twitter.com/raymondh/status/1184667350953447424) that it is possible to get logged out if you ignore the warning and try to open a file in IDLE when the System Preference is set to always open documents in tabs. I was able to reproduce with macOS 10.14.6 on real hardware (I didn't see elsewhere). This is clearly a Tk issue and there has been a lot of work going on in Tk in this area since Tk 8.6.8. We have been waiting for an official 8.6.10 release to again try to update the python.org built-in Tcl/Tk after the very unsatisfactory experience with 8.6.9; until then still best to heed the warning! |
Should be: "I did't *try* elsewhere.", not "see elsewhere". |
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:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: