Repository navigation
In Idle, Mac tabs make editor status line disappear. #79045
Description
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:
assignee = 'https://github.com/terryjreedy'
closed_at = <Date 2018-11-11.05:42:08.860>
created_at = <Date 2018-10-01.19:36:12.948>
labels = ['3.8', 'expert-IDLE', 'type-feature', '3.7']
title = 'In Idle, Mac tabs make editor status line disappear.'
updated_at = <Date 2019-10-17.04:58:11.211>
user = 'https://bugs.python.org/andyharrington'bugs.python.org fields:
activity = <Date 2019-10-17.04:58:11.211>
actor = 'ned.deily'
assignee = 'terry.reedy'
closed = True
closed_date = <Date 2018-11-11.05:42:08.860>
closer = 'terry.reedy'
components = ['IDLE']
creation = <Date 2018-10-01.19:36:12.948>
creator = 'andyharrington'
dependencies = []
files = ['47846']
hgrepos = []
issue_num = 34864
keywords = ['patch']
message_count = 31.0
messages = ['326822', '326844', '326846', '326976', '326993', '326995', '326997', '327024', '328797', '328828', '328888', '329659', '329660', '329661', '329662', '329664', '329665', '329666', '329675', '329710', '329712', '329714', '329717', '331272', '331274', '331277', '331740', '331889', '331933', '354829', '354830']
nosy_count = 6.0
nosy_names = ['terry.reedy', 'taleinat', 'andyharrington', 'wordtech', 'ned.deily', 'miss-islington']
pr_nums = ['10456', '10457', '10458', '10464', '11013', '11014', '6665']
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue34864'
versions = ['Python 3.6', 'Python 3.7', 'Python 3.8']
Activity
andyharrington commentedon Oct 1, 2018
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.
terryjreedy commentedon Oct 2, 2018
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.
andyharrington commentedon Oct 2, 2018
This appears to be a system settings option in Mac OS Sierra set under the
Dock, "prefer tabs when opening documents". With that choice, when there
is the tab bar in an Idle edit window (more than one window superimposed,
with tabs) the the whole bottom line with the horizontal separator line
segment disappears: seems like no allowance is made for the vertical space
taken up by the tab bar at top. There is a workaround: turn off this OS
option, but unfortunate to need to do that, and the user has no warning
that it is necessary. I only noticed this when I switched to a new machine
and was doing initial diddling with the system options, and did not realize
that i was not setting it up as I had it on my previous machine.
Dr. Andrew N. Harrington
Computer Science Department
Graduate Program Director gpd@cs.luc.edu
Loyola University Chicago
207 Doyle Center, 1052 W Loyola Ave.
http://www.cs.luc.edu/~anh
Phone: 773-508-3569
Dept. Fax: 773-508-3739
aharrin@luc.edu (as professor, not gpd role)
On Mon, Oct 1, 2018 at 9:30 PM Terry J. Reedy <report@bugs.python.org>
wrote:
taleinat commentedon Oct 3, 2018
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.
ned-deily commentedon Oct 3, 2018
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.
ned-deily commentedon Oct 3, 2018
One more time:
"Further, when opening yet edit window" should be "Further, when opening yet another edit tab (in the same IDLE window)"
terryjreedy commentedon Oct 3, 2018
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.)
[-]In Idle, Mac tabs make bottom editor line with cursor location disappear[/-][+]In Idle, Mac tabs make editor status line disappear.[/+]wordtech commentedon Oct 4, 2018
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.
taleinat commentedon Oct 29, 2018
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.
13 remaining items
taleinat commentedon Nov 11, 2018
Can we detect whether this system preference is enabled? If so, perhaps
IDLE should display a prominent warning.
taleinat commentedon Nov 11, 2018
See PR #54673, which warns if "Prefer tabs when opening documents" is set to "Always".
terryjreedy commentedon Nov 12, 2018
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
"# renamed xyz.py" or "# merged into abc.py". An possible example of the latter is merging autocomplete_w.py into autocomplete.py. (I strongly suspect that the split was for a Java-esque one-class per module rule.) Can modules be made system specific without great hassle?
ned-deily commentedon Nov 12, 2018
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.
terryjreedy commentedon Nov 12, 2018
See bpo-35213 for 'macOS' changes.
terryjreedy commentedon Nov 12, 2018
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.
terryjreedy commentedon Dec 7, 2018
New changeset 9ebe879 by Terry Jan Reedy (Tal Einat) in branch 'master':
bpo-34864: warn if "Prefer tabs when opening documents" set to "Always" (bpo-10464)
9ebe879
miss-islington commentedon Dec 7, 2018
New changeset 2db190b by Miss Islington (bot) in branch '3.7':
bpo-34864: warn if "Prefer tabs when opening documents" set to "Always" (GH-10464)
2db190b
miss-islington commentedon Dec 7, 2018
New changeset 1066554 by Miss Islington (bot) in branch '3.6':
bpo-34864: warn if "Prefer tabs when opening documents" set to "Always" (GH-10464)
1066554
ned-deily commentedon Dec 13, 2018
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 :)
terryjreedy commentedon Dec 15, 2018
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.
terryjreedy commentedon Dec 16, 2018
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).
ned-deily commentedon Oct 17, 2019
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!
ned-deily commentedon Oct 17, 2019
Should be: "I did't *try* elsewhere.", not "see elsewhere".