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