On my computer (Windows 10, resolution: 3000 x 2000, scaling of UI elements set to 200%), clicking on Zoom Height makes Idle go full screen. Clicking on the same menu (now called Restore Height) does absolutely nothing: Idle stays in full screen mode.

If I run the program on a secondary monitor (4k), the height only changes, but nowhere enough to be equal to the height of the screen.

On Windows 10, I'm seeing the same thing as @aroberge, but there's some more. I'll enumerate the steps.

1. Start IDLE.
2. Zoom Height -- window now takes up full screen.
3. Restore Height -- nothing happens.
4. Use Maximize/Minimize from title bar -- window goes back to original size and location.
5. Zoom Height -- window expands past bottom of screen, but top of the screen doesn't move. The status bar (and bottom of the editor frame) cannot be seen.
6. Restore Height -- restores to original size and location.
7. Moving the window around (that is, where the top of the screen is above or below the original), the window always 'snaps' to the same top, which is where is was originally opened.

Another path:

1. Start IDLE.
2. Maximize window using the title bar icon.
3. Menu says 'Zoom Height', but selecting it does nothing.
4. Continue from step 4 above.

This seems like a different bug/enhancement (to not allow zooming when the window is maximized), but I wanted to mention it since I was checking the behavior.

Thanks!

I've fixed three different issues on Windows 10, including those brought up here. I've also verified that it still works as intended on macOS (10.14.4).

@aroberge, @csabella, would you mind giving this another go?

It works correctly on my system.

It is a bit surprising to see the window taking the full screen for a second and then having its width reduced again, but it only does that when changing the zoom status for the first time. Moving the window to a second monitor with a different resolution after having clicked on zoom height at least once results in the zoom height feature not working properly as it remembers the settings from the first window. However, if one first moves the window to a second monitor and then clicks on the button, it works.

Moving the window to a second monitor with a different resolution after having clicked on zoom height at least once results in the zoom height feature not working properly as it remembers the settings from the first window.

This is true and very unfortunate. Many people use multiple monitors with different resolutions these days, so this should be considered a common scenario.

To avoid this, we could check the screen dimensions and only cache values for screens with identical dimensions. We'll also need to properly handle screens with identical resolutions but different scaling settings.

The test failures were all for test_enum. False positives with respect to this patch. Since test_idle passed on my machine, no need to retest with close/open -- wait until another commit.

Testing and commenting without looking at the code yet. There seem to be three issues, starting with what I think is the highest priority.

1. Initial full-screen flash: really annoying. If we cannot find something we have missed so far (I don't expect this), it might be better to pause it a bit. Idea: maximize the root window with text such as "Calibrating zoom". Or do this on startup as a splash screen with text such as "IDLE is measuring\nyour screen." The latter might require pulling startup code from pyshell into a separate startup file that does not immediately import all of idlelib. I don't currently know where the startup time goes, and if the time between creating root and displaying a shell or editor screen could be made long enough with pyshell as startup.

After this, Zoom and Restore work as they should. Thanks Tal. I think reducing the flash annoyance would be enough to merge.

2. User maximizes the window and then 'zooms'. Nothing happens as the window is already zoomed and zoom/restore do not change width. 'Zoom' is not changed to 'Restore'. Perhaps a comparison needs to remove '='? Perhaps when no calibration is stored, max can be stored and 'zoom' flipped?

3. Moving between a window between multiple screens. Given multiple screens, how common is this? We should be able to identify screens sufficiently by size and scaling. It does suggest that a startup check is not enough, and that both zoom and scale calibration need to be per window. Also, that user should be able to initiate recalibration for a particular window.

The newest change calculates and caches the needed info once per screen resolution.

This will still misbehave slightly in truly rare edge-cases, such as changing the size or position of the taskbar/dock.

1. Initial full-screen flash: really annoying. If we cannot find something we have missed so far (I don't expect this), it might be better to pause it a bit. Idea: maximize the root window with text such as "Calibrating zoom". Or do this on startup as a splash screen with text such as "IDLE is measuring\nyour screen." The latter might require pulling startup code from pyshell into a separate startup file that does not immediately import all of idlelib. I don't currently know where the startup time goes, and if the time between creating root and displaying a shell or editor screen could be made long enough with pyshell as startup.

IMO the number of users who actually use "zoom height" is small, so I don't think this justifies annoying 100% of the users with a maximized (i.e. almost full-screen) splash screen.

I've been working around and through the limitations of Tk as far as possible, and have reached the limit of what is possible, to the best of my understanding and research. To do better would require using OS APIs directly, e.g. as done by the screeninfo library, but IMO this is not warranted in this case.

2. User maximizes the window and then 'zooms'. Nothing happens as the window is already zoomed and zoom/restore do not change width. 'Zoom' is not changed to 'Restore'. Perhaps a comparison needs to remove '='? Perhaps when no calibration is stored, max can be stored and 'zoom' flipped?

I've currently made "zoom height" be a no-op when the window isn't in the "normal" state, e.g. when it is maximized. I can handle the case where the screen is already maximized if you find the current "do nothing" behavior surprising. Or I can just add a .bell() call to make it clear that the command failed.

3. Moving between a window between multiple screens. Given multiple screens, how common is this?

These days, with widespread use of laptops, it is very common: People connect and disconnect to/from external screens, using them instead of/in addition to the laptop screen. Also, multi-monitor desktop setups are increasingly common for developers, and often they do not have the same resolution, e.g. having one monitor situated in a "portrait" orientation.

... We should be able to identify screens sufficiently by size and scaling. It does suggest that a startup check is not enough, and that both zoom and scale calibration need to be per window.

The latest commit in the PR handles this properly. (Note that as far as Tk is concerned, scaling simply means a different resolution.)

When you're done making the requested changes, leave the comment: I have made the requested changes; please review again.

And if you don't make the requested changes, you will be poked with soft cushions!

I have made the requested changes; please review again.

@terryjreedy, indeed this appears ready to merge IMO, apart for my comment regarding the NEWS entry.

Thanks @taleinat for the PR, and @terryjreedy for merging it 🌮🎉.. I'm working now to backport this PR to: 3.8.
🐍🍒⛏🤖

Thanks @taleinat for the PR, and @terryjreedy for merging it 🌮🎉.. I'm working now to backport this PR to: 3.7.
🐍🍒⛏🤖

Sorry @taleinat and @terryjreedy, I had trouble checking out the 3.8 backport branch.
Please backport using cherry_picker on command line.
cherry_picker 5bff3c86ab77e9d831b3cd19b45654c7eef22931 3.8

GH-14167 is a backport of this pull request to the 3.7 branch.

Thanks @taleinat for the PR, and @terryjreedy for merging it 🌮🎉.. I'm working now to backport this PR to: 3.8.
🐍🍒⛏🤖

GH-14168 is a backport of this pull request to the 3.8 branch.