Re: moving IDLE forward (was Re: IDLE in UK Schools)

On 8/4/2015 5:40 PM, Mark Roseman wrote:
>> 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),
> 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) 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)

Nick suggests making the new code the default, at least for 3.5.1.  He 
posted the following (and a bit more) to issue 24759.

"For 3.5.1+, I think there's no question that we want to show IDLE in 
the best possible light, and we want to try to do that by default. That 
means modernising it to use the best cross-platform features that Tcl/Tk 
has to offer (including ttk)."

We can make the final decision for each version just before the 
corresponding release by how we set use_ttk in config_main.def. Before 
that, I will have it on to test the new code. Before releases, we should 
ask others who can build python to also test. I also hope we can add 
additional unittests for the modules affected.

> - 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).

Once there is a ttk version of the file, I intend to generally leave the 
old versions alone. They are being kept for back-compatibility. That is 
why I asked to you for a 're-arrangement' patch before the ttk 
conversion patch for your configuration tab makeovers.  The only tab 
with overt bugs is the Keys tab.  If we can fix some of them before 
conversion, that would be nice, but it is not a blocker.  Ditto for 
enhancements to the extension configuration.

Once there are parallel files, the default answer to trans-port requests 
with be 'No'.

> - the new UI code having to support both Tk 8.4 (which doesn’t have ttk)
> and Tk 8.5+

Will not be done. For 3.6, Ned hopes to only compile for 8.6.  I presume 
that means 3.5 will be the last version supported for OS 10.5.

-- 
Terry Jan Reedy


_______________________________________________
IDLE-dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/idle-dev