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
IDLE-dev@python.org
https://mail.python.org/mailman/listinfo/idle-dev
