Repository navigation
IDLE: revise window size, placement startup options #68125
Description
| BPO | 23937 |
|---|---|
| Nosy | @rhettinger, @terryjreedy, @taleinat, @E-Paine |
| PRs |
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 = None
closed_at = None
created_at = <Date 2015-04-13.20:05:32.084>
labels = ['3.8', 'expert-IDLE', 'type-feature', '3.7', '3.9']
title = 'IDLE: revise window size, placement startup options'
updated_at = <Date 2021-05-28.07:22:23.705>
user = 'https://bugs.python.org/zektron42'bugs.python.org fields:
activity = <Date 2021-05-28.07:22:23.705>
actor = 'taleinat'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['IDLE']
creation = <Date 2015-04-13.20:05:32.084>
creator = 'zektron42'
dependencies = []
files = []
hgrepos = []
issue_num = 23937
keywords = ['patch']
message_count = 13.0
messages = ['240725', '240767', '240847', '241119', '241366', '367759', '367763', '367775', '367777', '394589', '394612', '394640', '394641']
nosy_count = 6.0
nosy_names = ['rhettinger', 'terry.reedy', 'taleinat', 'Al.Sweigart', 'zektron42', 'epaine']
pr_nums = ['19816', '25946']
priority = 'normal'
resolution = None
stage = 'patch review'
status = 'open'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue23937'
versions = ['Python 3.7', 'Python 3.8', 'Python 3.9']
Activity
zektron42 commentedon Apr 13, 2015
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.
AlSweigart commentedon Apr 13, 2015
+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.
rhettinger commentedon Apr 14, 2015
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.
AlSweigart commentedon Apr 15, 2015
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:
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.
terryjreedy commentedon Apr 17, 2015
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.
[-]IDLE start maximized[/-][+]IDLE: revise window size, placement startup options[/+]E-Paine commentedon Apr 30, 2020
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
E-Paine commentedon Apr 30, 2020
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?
terryjreedy commentedon Apr 30, 2020
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.
E-Paine commentedon Apr 30, 2020
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)?
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.
taleinat commentedon May 27, 2021
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".
terryjreedy commentedon May 27, 2021
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.
taleinat commentedon May 28, 2021
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?
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.
taleinat commentedon May 28, 2021
Ah, now I understand better, thanks for the clarification.
I currently consider this is a rather low priority.