Terry J. Reedy added the comment: The general issue of Idle title bars is definitely not finished, though I may close this issue and open others.
1. 'Python' versus "Idle' versus neither in titles (assuming not both). 1a. Shell: Since the link in msg183874 is dead, I don't know what Bagrat suggested. I said 'Python' in msg183932, hinted 'Idle' in msg184620, and pushed the patch that had 'Python'. I could argue either way, but 'Python x.y.z Shell' (versus 'Idle x.y.z Shell') works as the name of the Idle product and also identifies what will run the code entered. I am now thinking 'neither' and propose making the title 'Shell x.y.z' -- see the more on this below. 1b. Editor: The patch I applied followed the same pattern, and again, I could argue for either 'Idle x.y.z' (what is doing the editing) or 'Python x.y.z' (what will run the code with F5)'. In this and the shell case, the version is the most important new information. If we consider the titles of other windows (see still more below), I think the class title should be 'Editor x.y.z'. 1c. OutputWindow: This is a bit tougher. 'Output' only works, sort of, as long as the class is only used for FIF, (Find in Files, grep). The initial title is actually '*Output*', indicating unsaved content, with no file name specified. Once saved, the title changes to "Output - <file name>". This is a precedent for 'Editor - <file name>' Since this issue started about adding versions, and version is not relevant to this and the following windows, a patch for OutputWindows should be a new issue. However, the design options need to be considered together. 1d. Read-only windows: We have "Debug Control", "Path Browser", and "Class Browser - Output Window". (For the last, "- Output Window" should go since it adds nothing and misleads in that the window is not an OutputWindow. It could be replaced with the class name.) 2. Order of generic and specific (or class and instance) components. Most windows have a generic title for windows of a class. Part of my thinking above in suggesting 'Shell x.y.z' and 'Editor x.y.z' for the respective classes is that none of the class titles should contain either 'Python' or 'Idle' [separate? issue 0 -- it would be a correction of the patches on this issue]. Once an OutputWindow is saved, its title has a generic and specific component, in that order. The specific component identifies the specific contents of the instance. While I expect to replace 'Output' with names that reflect the subclasses of usage, the pattern will remain the same [separate issue 1]. Before we added a generic component for editor windows, they were unique in not having one. They currently follow the output pattern. I am also thinking a giving the title for ClassBrowswer (which is really ModuleBrowser) a specific component -- the module name [separate issue 2]. My point is that we have gone from one generic-specific (class-instance) name pair to two, and soon to more. If someone wants one pair flipped, then it seems logical to me that the same person would want all such pairs flipped, for the same reason. Bagrat, is this true for you? I know you only mentioned editor pairs, but you may not have known about output pairs, and certainly not future pairs that do not exist yet. I am willing to consider a user-settable option [separate issue 3], but I would think it should cover all such pairs, and not just editor window pairs. Currently, editor window titles are also unique in repeating part of the specific title. Output windows, when saved, do not repeat the short file name. Do any other editor programs do this? I expect we may decide to eliminate the redundancy as it exist now. Notepad++ puts "<complete path> - Notepad++" on the title bar and the filename on the notebook tab. When the tabbed selected changes, the title bar changes. Firefox does the title to match the tab also. There is already an issue to use tabbed notebooks with Idle and when we do that, I would expect to remove the duplication in the title and imitate Notepad++. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue17390> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
