I feel like IDLE should start maximized as opposed to starting... 'unmaximized' I guess. Maybe instead of the current option to start the window at 'blank' by 'blank' size, it should be a check button that defaults to maximized and can be turned off to start it at the default height and width.

+1 to this idea. In classroom settings when I look over the shoulder of students, usually they're working with IDLE or an editor in a much smaller window. When I point out how to maximize it, they always enjoy the additional space.

It seems like a minor thing, but a lot of newbies don't realize they can maximize the window. Having this as the default start state is a good idea.

I'm trying to think of why you would want it to start windowed, and can't come up with anything.

I also teach students and prefer the current behavior.   It is egregious for apps to assume that they are the only thing running and to hide everything else (i.e. docs viewed through a browser).  This isn't the norm for most apps I work with either.

Though I'm -1 on this, I would support adding IDLE configuration option so that the user can specify that they want maximization.

> It is egregious for apps to assume that they are the only thing running

I would agree for most apps, but I tend to think of IDEs as something that is generally run full screen. I'll note that Eclipse starts maximized, while PyCharm starts windowed.

Though both will remember their state when the program is closed, and resume it the next time it starts. IDLE, however, always follows the width/height info in the config-main.def file.

I propose the following:

- Remove the "Initial Window Size" UI elements from the Configure IDLE window (Minimizing the number of choices the user must make on a config page keeps it uncluttered.)
- Keep the config-main.def file settings, but have IDLE update it on exit. The next time IDLE starts it will have its previous size.

This way if the user maximizes IDLE's window and then exits, it will start maximized the next time IDLE starts. Though I still think starting maximized as the default would be a good idea.

With a large, wide monitor, I run very few things maximized other that a browser and full screen games.  A much smaller notebook screen would be very different.  For Idle, I want Shell and Editor side-by-side.  I would however, like windows vertically maximized, as with Window => Zoomheight, except that Zoomheight is buggy in that it ignores the taskbar and puts the Idle status bar underneath.  (Maximize does not do this.)

The idea of removing the option and remembering the last position is worth considering, but there may be multiple windows upon closing.  I would actually like the horizontal positioning of shell and editor kept separate.  So I agree that initial window size and position could be improved, but I am not sure how.

I have made a few simple changes to the configdialog.py, config-main.def & editor.py which adds a "Maximised" checkbutton to the general page (just above the existing entries). The default is for this to be false (based on the previous comments in this PEP), but it is there for those of us that feel it would be a very nice feature.
Three questions:
1: Is changing the anchor on the label correct (visually) or is it better to leave it so that it centres?
2: Are we happy that the default should be for this to be disabled?
3: Is the description "max" sufficient for the configs

Sorry, two more things:
1: Can someone please check this behaves properly on MacOS (I have checked on Windows and Linux)
2: Is setting the checkbutton side to "TOP" correct, or is there a better way of achieving the same layout?

I think we are at the point where the General tab needs to be split into 2 tabs, or else widened.  On my Macbook, the bottom buttons are not visible.

One of the constraints of any change is that .idlerc/config-main.cfg remain compatible with older releases.

> I think we are at the point where the General tab needs to be split into 2 tabs, or else widened

I definitely agree (possibly split into "Window" and "Editor/Shell"), but that would be a separate PEP wouldn't it (possibly one that needs to be pulled before this one can proceed)?

> .idlerc/config-main.cfg [must] remain compatible with older releases

Would an new (unknown) option, therefore cause issues? I am just creating a new field, not changing/re-purposing an old one, which (correct me if I'm wrong) would just be ignored by old versions.

In terms of its interface, IDLE is more like a REPL + text editor than what is commonly thought of as programming IDEs (Visual Studio, PyCharm/IDEA, Matlab, JupyterLab etc.)  Terminals and text editors almost universally do not launch maximized by default.  Therefore I think starting IDLE maximized would be an unnecessary departure from the common, expected UX of similar desktop apps.

I suggest closing this as "won't fix".

When I changed the title, I intended to broaden the issue beyond 'start maximized'.  Even for that, there are two possibilities. 1. Configure option (default as now).  2. Save 'current' position, which helps non-maximizers also.  So I am inclined to the latter with some definition of current.

If we add multiple panes, maximized will make more sense.

There is a subtle issue easy to not notice.  Scrolling is slightly different when the window height an integral number of lines, as it now is on startup, or pixels, as after resizing with zoom or mouse grab.  I believe 'lines' is enough better that I have considered snapping to 'lines' after changes.  Not now though.

The Settings dialog height is currently determined by the General tab.  It is already too high for some notebooks: on my macbook, I can barely click OK (with 'OK' not visible) *after* putting the app bar on the side rather than bottom.  We need to squeeze existing items rather than add another.

> There is a subtle issue easy to not notice.  Scrolling is slightly different when the window height an integral number of lines, as it now is on startup, or pixels, as after resizing with zoom or mouse grab.  I believe 'lines' is enough better that I have considered snapping to 'lines' after changes.  Not now though.

This is mostly a separate issue.  I certainly think that scrolling should be consistent, independent of whether the window show a whole or fractional number of lines.  Terry, is there an issue open about that or shall we open one?

> The Settings dialog height is currently determined by the General tab.  It is already too high for some notebooks: on my macbook, I can barely click OK (with 'OK' not visible) *after* putting the app bar on the side rather than bottom.  We need to squeeze existing items rather than add another.

This is entirely separate.  It has been mentioned before, but again I'm not aware of an existing issue specifically about this.  If there isn't one, let's create one and discuss there.

> When I changed the title, I intended to broaden the issue beyond 'start maximized'.  Even for that, there are two possibilities. 1. Configure option (default as now).  2. Save 'current' position, which helps non-maximizers also.  So I am inclined to the latter with some definition of current.

Ah, now I understand better, thanks for the clarification.

I currently consider this is a rather low priority.