> Hi, this is Al. I haven't had much time to work on IDLE Reimagined in recent > months, but I'd like to get back on it in a couple weeks. Mostly I've been > following a rabbit hole of: > > * I need to make this project approachable for new contributors... > * So I want to document the code... > * But first I should refactor it to simplify it... > * But first I should make the unit tests complete to avoid breaking > anything... > * But first I need to learn tkinter for the gui tests... > > etc. But I'm still committed to a UI overhaul of IDLE as a newbie tool that > is bundled with Python.
Hi Al, That is awesome! Let’s make sure we don’t duplicate effort, particularly in the ‘prep’ work to improve/simplify the current code. As someone who is very familiar with Tk (see. http://www.tkdocs.com <http://www.tkdocs.com/>), I’ve been working the last week or so at updating the current appearance, and subsequently expect to simplify lots of the underlying code. As I’ve been working with it, I see lots of great opportunities to make it easier for people to modify it. One big issue that Terry is presently working hard to sort through (see http://bugs.python.org/issue24759 <http://bugs.python.org/issue24759>) is the ‘backwards compatibility’ aspect, which from my current reading suggests we’d be stuck with both “old” and “new” UI code side-by-side until Python 3.6. That makes the maintenance and modification more difficult of course. I’m still trying to get my head fully around all the implications. Some of the structural aspects (refactoring, reorganizing dialogs, etc.) could be addressed to simplify the code before an option to use ttk widgets is added. But, as Terry points out, if there are people out there using *pieces* from idlelib, doing too much in the way of structural changes could mess things up for them. So significant structural changes to the current code base seem out. Instead, new UI code (based more on ttk) would go in brand new files, not having any backwards compatibility constraint. Those ones can be reorganized/restructured to everyone’s heart’s content, may not even resemble corresponding parts of the existing code, and could serve as a great base for more significant changes that might better facilitate its use for learners. So it’s almost like we have a fork and an original sitting side-by-side in stdlib until at least 3.6. How do we decide which to use? - programs using pieces of idlelib, and people with Tk 8.4: - they run the code as it exists now (current UI, current structure) - for people running IDLE (as a whole) and having Tk 8.5+: - for now, by default, they get the old code (current UI, current structure) - if they want, they can flip an “experimental” switch to try the new code (improved UI, improved structure) - at some point in the future (when the new stuff is stable enough), we change things so they get the new code by default The old code gets marked as deprecated, with plans to remove it altogether at some point in the future. Two things I would be fairly nervous to see happening: - requests for (non-trivial) UI improvements (which will be in the “new UI” code) to be “ported” to the existing code (which can’t have major structural changes). - the new UI code having to support both Tk 8.4 (which doesn’t have ttk) and Tk 8.5+ Any thoughts? Mark
_______________________________________________ IDLE-dev mailing list IDLE-dev@python.org https://mail.python.org/mailman/listinfo/idle-dev
