<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class="">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:</div><div class=""><div dir="ltr" class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><br class=""></div>* I need to make this project approachable for new contributors...<br class=""></div>* So I want to document the code...<br class=""></div>* But first I should refactor it to simplify it...<br class=""></div>* But first I should make the unit tests complete to avoid breaking anything...<br class=""></div>* But first I need to learn tkinter for the gui tests...<br class=""><br class=""></div>etc. But I'm still committed to a UI overhaul of IDLE as a newbie tool that is bundled with Python.</div></div></div></blockquote><br class=""></div><div><br class=""></div><div>Hi Al,</div><div><br class=""></div><div>That is awesome! Let’s make sure we don’t duplicate effort, particularly in the ‘prep’ work to improve/simplify the current code.</div><div><br class=""></div><div>As someone who is very familiar with Tk (see. <a href="http://www.tkdocs.com" class="">http://www.tkdocs.com</a>), 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.</div><div><br class=""></div><div>One big issue that Terry is presently working hard to sort through (see <a href="http://bugs.python.org/issue24759" class="">http://bugs.python.org/issue24759</a>) 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.</div><div><br class=""></div><div>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.</div><div><br class=""></div><div>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. </div><div><br class=""></div><div>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?</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>- programs using pieces of idlelib, and people with Tk 8.4:</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>- they run the code as it exists now (current UI, current structure)</div><div><br class=""></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>- for people running IDLE (as a whole) and having Tk 8.5+:</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>- for now, by default, they get the old code (current UI, current structure)</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>- if they want, they can flip an “experimental” switch to try the new code (improved UI, improved structure)</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>- at some point in the future (when the new stuff is stable enough), we change things so they get the new code by default</div><div><br class=""></div><div>The old code gets marked as deprecated, with plans to remove it altogether at some point in the future.</div><div><br class=""></div><div>Two things I would be fairly nervous to see happening:</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>- 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).</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>- the new UI code having to support both Tk 8.4 (which doesn’t have ttk) and Tk 8.5+</div><div><br class=""></div><div>Any thoughts?</div><div><br class=""></div><div>Mark</div><div><br class=""></div><div><br class=""></div><div><br class=""></div><div><br class=""></div><div><br class=""></div><div><br class=""></div><div><br class=""></div><div><br class=""></div><div><br class=""></div><div><br class=""></div><div><br class=""></div><div><br class=""></div><div><br class=""></div><div><br class=""></div><div><br class=""></div></body></html>