Terry J. Reedy added the comment: There over-arching issue is that IDLE was not built to allow addition of new builtin themes. IDLE New is currently identical to IDLE Classic, so maybe that was intended to allow a revision of IDLE Classic (and I have an idea for that), but IDLE Dark is too drastically different to have added it as IDLE New. There are two sub-issues here.
1. Theme loading: I experienced the multiple error messages to console behavior once, but only once. This is the 'or worse' in the new message. I could not find out why only once, or know that the same would be true on other machines. If possible, there should only be one message. Whether it goes to console or messagebox is a different issue, part of revisiting the configure error message system. The first fallback should be to existing and accessible builtins, namely IDLE Classic, rather than a default of no colors. This strikes me as a buggy design. 2. New theme addition and selection: This has to take into account that we cannot patch existing releases and that all IDLEs used by one user use the same user configuration files. (There is an issue post that suggests maybe changing this, but I cannot find it now.) This is a minus in that we cannot currently restrict selection of IDLE Dark to new IDLEs (but see below). This is a plus in that IDLE Dark can be 'backported' by saving as a custom theme. We may always need some sort of message. I thought about automatically saving as a custom theme, but besides the presumed deadline for 3.4.4 (see below), there are potential problems. A) It is magical and potentially confusing enough that I might want a message anyway. B) It may not be possible (no writable .idlerc). I am not sure what happens if not. C) If we write with the same name, 'IDLE Dark', then two things have the same name but may or may not be identical. (Users could modify the custom version of IDLE Dark.) This is why the interface demands a new name. Your patch assumes that they stay identical. D) If we write as a different name, users need to be notified anyway. Might as well let them choose, so they remember. E) A custom version is not needed for students in a class with only one IDLE on the machine. F) We would have to look at possible interactions with other parts of the dialog's behavior. "See below", time pressure: I though 3.4.4c1 was due out today. It has not appeared, and there have been no pydev messages for 20 hours, since I posted an enquiry out the release. If the release is a week away, we can potentially change the patch, though I would want to test very carefully. "See below", date-specific user config: because all releases after today will have IDLE Dark, the needed marker is date rather than version. Right now, selecting 'IDLE Dark' as a built-in theme results in user config-main.cfg having this section. [Theme] default = True name = IDLE Dark Suppose instead the result were [Theme] default = True name2 = IDLE Dark #or [Theme] default = True name = IDLE New name2 = IDLE Dark I tested with 2.7.10 and it starts fine with either of the above, and just as important, writes the above when Classic or New are selected if the name2 line is there. I expect the both should be true of all versions that recognize user config files, especially the startup part. The challenge would be to have new IDLEs add the name2 line when IDLE Dark is selected and have it replace name with name2 when fetching the name. The message could then be something to the effect of "IDLE Dark only comes with IDLE releases in Oct, 2015 and later. To make it available to older releases, save it as a custom theme (with a new name)." This is a bit clumsy, and would have to be generalized for further theme (but YAGNI for now), but would eliminate errors and no color with old versions. What do you think? ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25313> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
