[Idle-dev] moving IDLE forward (was Re: IDLE in UK Schools)

[Al Sweigart]

Can we collect a list of software that uses idlelib? I'm not sure if it
would affect a significant number of projects. Since IDLE has always been
an application rather than a standard library module with a published API,
I don't feel like this should hold back IDLE development. (Or am I wrong in
this view of idlelib?)

Many of the changes that I'd like to see are cosmetic or new features
instead of restructuring. The single window, tabbed design is the only
non-trivial UI change, and even then it's reusing PyShellEditorWindow and
OutputWindow instead of creating new UI components.

Using the post-8.5 widgets really would improve the look of IDLE, but
personally I don't mind if these have to be held off until 3.6. We'll have
our work cut out even without maintaining two sets of widgets just for 3.5.

Overall, I'd defer to Mark and Terry's judgement. My current plan is to get
more familiar with ttk (Mark's book has been great!) and the code base, and
also think of what "new contributor" documents we should write up.

Are there any bug issues and mailing list threads that would be in
particular good for new contributors? Also, any questions in this thread I
haven't addressed?

-Al

On Tue, Aug 4, 2015 at 5:40 PM, Mark Roseman <mark at markroseman.com> 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)
> - 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 at python.org
> https://mail.python.org/mailman/listinfo/idle-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/idle-dev/attachments/20150805/aa6b7b1a/attachment.html>