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
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:

Terry J. Reedy <tjreedy@udel.edu> added the comment:

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.

----------
nosy: +ned.deily, taleinat

---

Python tracker <report@bugs.python.org>
<https://bugs.python.org/issue34864\>

---

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.

New changeset 50ff02b by Terry Jan Reedy in branch 'master':
bpo-34864: Document two IDLE on MacOS issues. (GH-10456)
50ff02b

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.

https://en.wikipedia.org/wiki/MacOS

New changeset b91c27d by Miss Islington (bot) in branch '3.7':
bpo-34864: Document two IDLE on MacOS issues. (GH-10456)
b91c27d

New changeset a650493 by Miss Islington (bot) in branch '3.6':
bpo-34864: Document two IDLE on MacOS issues. (GH-10456)
a650493

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
IDLE should display a prominent warning.

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
"# 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?

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.

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

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

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

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".