[Idle-dev] IDLE and ttk

[Terry Reedy]

On 7/15/2015 6:24 PM, Mark Roseman wrote:

As the date above shows, this somehow got hung up in the mailman 
machinery until Mark wrote the list owners and someone got it released. 
  In the meanwhile, Mark sent this to me directly, and I already 
responded.  But I will summarize and revise what I wrote back.

> I just joined this list, and would like to reopen the subject of
> migrating some of the “old school” tkinter user interface elements to
> use ttk.

This subject was dormant, waiting the right time for reactivation, 
which, with your offer, I think is now.

> From browsing the list archives, I see this was last substantially
> discussed in 2010, and several people over time have done some
> hacking in this direction, though nothing that has ever made it into
> IDLE. Part of the issue then appeared to be contributer/maintainer
> time constraints… is this still the case now?

A combination of time, tests, priorities, knowledge, and back-compatibility.

Time: Mark is offering that.

Tests: a year ago, I and a GSOC student set up a human-test framework as 
a complement to automated unittests.  It makes it much easier to check 
appearance changes as well as do manual testing of hard-to-automate (or 
not-yet-automated) behavior checks.

Priorities: the worst crash issues, and some other bugs, have been fixed 
since 2010.  While some behavior bugs remain, appearance can also 
detracts from usability.  As noted below, some ttk additions will make 
behavior changes easier.

Knowledge: Mark has that, and I know enough now (but not a year ago) to 
review work he does.

Back-compatibility: We do not know how much the private idlelib APIs are 
used, and if so which.  Refactoring files, upgrading to PEP8 standards 
(which is best done when a file is worked on and tested for other 
reasons) and upgrading to ttk widgets could all break compatibility.  So 
for dialogs, I would add new PEP8-compliant, grid and ttk-based files 
and mark the old ones deprecated (with a warning on import), to be 
removed in 3.6.

> I have a good chunk of time to do some work on this, and would be
> quite interested in taking it on, if there’s enough confidence that
> changes could be accepted at this point in time.

Unless someone has a convincing reason not to, I would like to go ahead 
with this.

> To be a bit more specific, the priorities would be:
> (1) updating the widgets,

This mostly means replacing the widgets in dialogs.

> (2) reworking layout/spacing (using grid) to be more consistent with platform expectations,

This is somewhat separate issue but I agree that .grid is easier to work 
with than the older .pack (which Idle currently uses).

> (3) replacing homegrown megawidgets like tabbed pages and tree widget with ttk built-ins, and

Until I patched it last Fall, TreeWidget, used for the path and module 
browsers, did not work right on Windows and it is still a bit flakey. 
Using the more capable and polished ttk.Treeview should make upgrading 
the browsers much easier.

> (4) minor adjustments to user interface to improve usability and/or
> similarity to other modern programs. For the latter, I’m referring to
> very localized improvements that reflect and respect the background
> and expectations of the target user base, not big changes in
> structure or scope.

Marks tutorial
http://www.tkdocs.com/tutorial/index.html
gives parallel ttk widget examples for Mac, Windows, and Linux. I 
presume these use the default theme for each platform.  The Button 
example is at
http://www.tkdocs.com/tutorial/widgets.html#button

> Just as an introduction, I’m the author of the tkdocs.com site, and
> the accompanying ‘Modern Tkinter for Busy Python Programmers’ book
> (and yes, I think a ‘case study’ chapter describing what it took to
> migrate from old to new would be a great addition to the book).

What Mark did not say is that he has used tk for over 2 decades and 
started the site nearly a decade ago.

-- 
Terry Jan Reedy