The screen shot shows the current version of the main IDLE window, with the little pics at the bottom indicating what it looks like when the window loses focus.  A few entirely cosmetic changes I'd like to make here:

1. Swap scrollbar for ttk scrollbar; this visually will affect the Linux version. Note that even the ttk scrollbar is somewhat out-of-date with current desktops, but it's a step in the right direction!

2. You'll notice the slight border around the text widget when active; barely visible on Windows, a bit more so on Linux, and very much there on Mac (this is the "highlightthickness" attribute). Current conventions on all three platforms do away with this, so it should be removed for IDLE.

3. Regarding the items in the status bar, I'm going to suggest removing the sunken reliefs around the two items. Again, this was all the range long ago, but most apps on all platforms now have more minimal decorations in those contexts. If there were more (different) things on the status bar, I might suggest a light vertical separator between sections, but here there's no need for decoration at all.

4. Color and border on status bar. It's most apparent on the Mac inactive window pic, where the status bar blends in to the editor. I plan on tweaking the status bar so it's always a light grey color, and has a small darker separator above it. I may see about tweaking the font, as status bars tend to use a slightly smaller font nowadays.

5. Spacing for icon size grip on Mac should be removed for recent versions of OS X. This hasn't been necessary since before OS X Lion (released 2011). I can have the code include it when running on earlier versions of OS X.

These are all tiny changes, but combined with a decent font make a big difference visually when IDLE first starts up.

Ned, Mark will be opening several appearance issues (see ttk thread on Idle list).  Do you want to be routinely added as nosy to comment?

Mark: The description and labeling of the screenshot is a bit off. For Windows, the full window is inactive ([ x ] is not red). The Linux and Windows inset labels are reversed (and the Windows one inactive).

1. I added the ttk import and prefix to EditorWindow and hit F5 to test. The result matches what appears to be the native Win7 scrollbar.  I am ready change all the scrollbars.  Lets make this a separate first patch.

2. The current Tk/Toplevel frame appears to be the native frame, at least on Win7. So I do not see anything to be done away with to match the platform.  The semi-transparent frame gets grayer (less transparent) when active.  There is additional darkening along the bottom and up 3/4 the sides.  I do not care about Win8 as, judging from Stackoverflow, it seems to be less common among Idle users. I expect Win 10 will eventually be a different matter.  I will eventually upgrade after I get the notice.

3. I agree with deleting the sinks: useless and ugly. I do not believe anything else has a status bar.

There is much wasted space.  Notepad++ has file type, length (chars), lines, lineno, colno, selection length, "Dos/Windows"??, "ANSI"??, and  Ins(ert versus Overwrite on insert - not available with Idle). I am not sure what would be useful, but adding stuff would be a separate issue.

4. Windows bar looks fine to me.  Light gray, same active or not. For me, the font, the same as on the menu, is already small. No smaller. In fact, I have wondered whether it would be possible for users to adjust the size of the 'other' fonts also.

5. Ned's territory.

Sounds good. To clarify, (2) refers to not the overall window, but just around the text widget. Both regarding this and the comments regarding status bar (4), things look really good now on Windows. The changes I've made are barely perceptible there, but improve things a bit more on Linux, and way more on Mac.

The attached mainwin.patch implements these few small changes (except for removing the Mac grow box space); checked active/inactive on Mac, Windows, Linux.

I added a dependency to gracefully exit when no ttk.

Mark: If you have not yet, please sign PSF Contributor Agreement before submitting further patches.
https://www.python.org/psf/contrib/
https://www.python.org/psf/contrib/contrib-form/

I now see what you mean -- the active text border for linux and mac. I cannot see anything on Windows with side-by-side text windows, even with a magnifier, so if there is a change, it is too subtle for my eyes.

I am working on a scrollbar patch for the other files.

Great. Sent in the contributor agreement Monday so I assume it should percolate through soon.

Looks fine on Windows.  Now to be picky: Is it possible to move 'Col:' to the left, leaving space to the right, so that 'Col:' does not move when going from 9 to 10? Ditto for 'Ln:'?

The mainwin2.patch keeps the width of the fields constant. Thanks!

I patched the other scrollbars for 3.4 and verified the expected appearance change.  For 2.7, with 8.5.15, I so not see any difference.  Is this what I should expect on Windows?  Did ttk.Scrollbar only use the Win7 scrollbar in 8.6?

I assume that change should be apparent on 2.7 with other system, but I'd like to make sure that I have not missed anything.  I am otherwise ready to commit these.

Hmm, the problem with maxsize = constant is occasionally losing a trailing digit or two.  For instance, if one enters 8**2222, one might be interested in the number of digits and put cursor at end of wrapped line.  But trailing 7 of 2007 is missing.  Is there any (sensible) way to have min with no max, like printf and python formatting?
>>> '%3d' % 1111
'1111'

> Ned, Mark will be opening several appearance issues (see ttk thread on Idle
> list).  Do you want to be routinely added as nosy to comment?

No, that's not necessary or desirable.  At the moment, I don't think I have much bandwidth or expertise to contribute to appearance discussions.  I'll chime in if asked or if anything strikes me.

As a general principle, do keep in mind that for each current actively maintained Python release (e.g. 2.7, 3.4, and 3.5), on python.org we supply two Python installer variants for OS X: (1) for OS X 10.6 and higher that links with Tcl/Tk 8.5 and (2) for OS X 10.5 (and higher, although intended primarily for 10.5) that links with Tcl/Tk 8.4.  So any changes for IDLE for 2.7, 3.4, and 3.5 should work across all of those combinations of OS X releases and Tk versions.  (For Python 3.6, I'd like to move to shipping with just Tk 8.6, if possible.)  Also, there are third-party distributors of Python for OS X that currently link with Cocoa Tk 8.6 and with X11 Tk 8.6, for example, MacPorts.

https://www.python.org/download/mac/tcltk/

ttk is not available with 8.4 (except maybe with the tile extension, but I believe some changes were made before it was incorporated in 8.4 as ttk). As I mentioned on the ttk thread on idle-sig, it was agreed in a pydev discusion a couple of years ago or so that Idle could use ttk widgets and thereby require 8.5. 8.5 is about 8 years old. Tracker issues and pydev discussion about using ttk in Idle go back at least 5 years.  Two examples of the latter are "IDLE contributors and committers" and "Removing IDLE from the standard library" from July 2010. G. Polo's patches using ttk were part of the discussion.

Mark Roseman has used tk for 22 years and ttk for at least 8 and written a nice website and book on how to use them (which I have read).  He has offered to help upgrade Idle with ttk. I am excited about taking advantage of the offer.  This will alleviate many of the complaints about Idle's appearance and allow use of the (tabbed) Notebook, and Treeview widgets new with ttk. Even on Windows, the ttk Scrollbar is a noticeable improvement.

I do not want to keep Idle development frozen for the benefit of the few users of the 8-year-old Mac OS 10.5 who might also want to use Idle.  The alternatives I see are removing Idle from the 10.5 release; asking those who want Idle to upgrade to a new ActiveState distribution, if there is one that works on 10.5; or include with that release a frozen version of Idle as it was yesterday, before I applied the first patch importing ttk.

Nick, do you remember any of the pydev discussions, or have any comments?

I'll raise the practical matter that ActiveState no longer distributes 8.4.x as part of its Community edition ActiveTcl, though I presume it would be available as part of its for-fee Business version. Therefore if someone wants to use Python on 10.5, it would be with 8.4.7 (from 2005), pre-installed by Apple.

The real difficulty is not so much a 10.5 vs. 10.6, but support for any PowerPC Macs, since 10.6 was the first version that was Intel only. The last PPC Macs were sold in 2006.

FYI, the ActiveTcl 8.5.x Community edition are for 10.5+, but Intel only.

Out of curiosity, are there download statistics?

At some point, I'm sure it will make sense to stop distributing a pre-built Python that works on PPC/10.5; which doesn't of course preclude people from getting it working, or someone else creating a pre-built package hosted elsewhere.  That's a discussion worth having of course, but somewhat larger than the matter here.

My personal preference would be just making IDLE not work without ttk, i.e. it breaks if they don't otherwise get a PPC 8.5 Tcl/Tk compiled on their machine. I think Terry's suggestion of a 'frozen' IDLE might work on 2.7.x, but probably less so on 3.x. 

Not going ahead with the improvements (or keeping code for both 8.4 and 8.5+) doesn't seem like a sensible choice, given the benefits to a large audience.

Ned, quick question... if there is a tcl/tk 8.5.x on the system, will the 32 bit prebuilt distros link with it, or only with a 8.4.x version?

For years there have been people who want to remove Idle from the stdlib for all distributions, not just the OS 10.5 release. Even Guido is now having thoughts along this line.  One of the reasons is appearance.  Not improving that will make it more likely that it goes away for everyone. The other reason, of course, is behavior. I also believe the new widgets will make some behavior improvements easier.

I see no reason why Idle as it was yesterday should not continue to work as it did yesterday as well for 3.4 and 3.5 as for 2.7.

I would use optional import to support Tcl/Tk older than 8.5 in Python 3.4 and 2.7.

try:
    from tkinter.ttk import Scrollbar
except ImportError:
    pass

That does not work.  ttk widgets are not drop-in replacements for their predecessors.  The problem is illustrated by these lines from the TextViewer patch

-        self.scrollbarView = Scrollbar(frameText, orient=VERTICAL,
-                                       takefocus=FALSE, highlightthickness=0)
+        self.scrollbarView = ttk.Scrollbar(frameText, orient=VERTICAL,
+                                       takefocus=FALSE)

The highlightthickness option, among several others, is not legal for the ttk versions of widgets.  That is why I removed it. This particular instance could be solved by living without the highlightthickness option, but their will be many other instances where we do not want to drop the configuration. The API differences are probably even worse for Treeview and Notebook versus Idle's custom implementations of the same widget.

The last version of the patch works well for me and has a nice, elegant look.

Yes, but setting the highlightthickness option can be optional too.

    self.scrollbarView = Scrollbar(frameText, orient=VERTICAL,
                                   takefocus=FALSE)
    try:
        self.scrollbarView['highlightthickness'] = 0
    except TclError:
        pass

or

    self.scrollbarView = Scrollbar(frameText, orient=VERTICAL,
                                   takefocus=FALSE)
    if not ttk:
        self.scrollbarView['highlightthickness'] = 0

Otherwise I think it is not worth to apply these changes to maintained releases. 3.4 will switched to security fixes only mode soon, but 2.7 has long support term. Bugfix release should continue to work on platforms that are shipped with Tcl/Tk 8.4.

Serhiy, I appreciate what you're saying, but special casing to handle both ttk and non-ttk cases seems not feasible given the amount of resources available to enhance/maintain IDLE. Additionally, part of the rationale for making these changes is to simplify the code by leveraging things in ttk that aren't in 'classic' Tkinter.

Would you suggest:
(a) keep two versions of the IDLE code in the distro (one a snapshot)
(b) require 8.5 Tcl/Tk be installed on a system before IDLE can be used
(c) leave IDLE with its current (embarrassing) UI
(d) drop IDLE from Python altogether

On Idle-sig, in 'ttk appearance' Mark posted before and after screenshots of Preferences Font tab for Windows, Linux, and Mac
http://www.tkdocs.com/images/idle_cfgfont_ttk.png
Glyph, who I never knew read Idle-sig, calls the after shots great (I think he has a Mac, which sees the most improvement).

Mark: Serhiy is asking that we not make the change to maintenance releases, 2.7 and 3.4, without further discussion and agreement.  He is correct to do so.  I reread PEP 434 and it specifically says  "The PEP would apply to ..., but not necessarily to possible major re-writes such as switching to themed widgets ... ."  'Not necessarily' means 'only permitted with further discussion.  Further discussion should continue on #24759 which is specifically about this issue.

Ah, ttk detection doesn't work this way. ImportError is not raised on import, and TclError is raised instead on widget creation.

Here is a patch for 3.4 that is compatible with 8.4 (tested).

@scroll.diff LGTM for 3.5+.

Minor nit: you import 'ttkcompat' and add 'compat'.

On to the new 'compat': the only doc for .setup_master is the docstring
"If master is not None, itself is returned. If master is None,
    the default master is returned if there is one, otherwise a new
    master is created and returned."
So if master is always passed in, it seems that the call does nothing and could be removed.

._load_tile and ._tile_loaded have no doc. As near as I can tell from
>>> r = tk.Tk()
>>> s = ttk.Scrollbar(r)  # does not set ._tile_loaded on r
>>> ttk._load_tile(r)  # ditto, None returned
with 8.5, ._load_tile does nothing and ._tile_loaded is never set. They are only used for 8.4.  Correct?  If the tile extension is loaded, then use_ttk would be set to True.  Is the tile extension fully compatible with using ttk?

I would like compat.py to consist of an initialization functions that is called exactly once, always with a Tk(), to set globals in the module.

import tkinter as tk
from tkinter import ttk

def initialize(master, ttk_wanted=True): # untested
    globals use_ttk, Scrollbar, ...

    if not ttk_wanted:
        use_ttk = False
    else:
        try:
            ttk._load_tile(master)
        except tkinter.TclError:
            use_ttk = False
        else:
            use_ttk = True

    if use_ttk:
        from ttk import Scrollbar, ...
    else:
        from tk import Scroolbar, ...

Initialize would normally be called when Idle starts up.  ttk.wanted could make use_ttk a user option.  Initialize with ttk_wanted True/False would be used for testing.

While I think this approach would largely be a bad idea for an IDLE-sized application, where I think it definitely would be useful is in something very restricted like the tkSimpleDialog code. 

To improve the various little 'askstring', 'askinteger' etc. sprinkled throughout IDLE I had to do a copy/paste to change that code to use ttk widgets. Because that is an example of something very simple and self-contained, it could easily provide an option to do ttk or non-ttk widgets. 

Apologies if this is too off-topic.

Keep in mind that most option substitution would be at the file rather than widget level.  The scrollbar switching would be for something like editor windows, which are basically generic.  For the option dialog, we would copy ConfigDialog.py to, say, configuration.py, adjust the imports, and convert to ttk (and pep8, as we wish).  Then use_ttk would be used for choosing which file's ConfigDialog to bind to the Configure IDLE menu item.

Back to Editor Windows: I have a new idea for the status bar

First: move ln, col to the left, replace the label with a label + entry box.  If someone edits the line number and hits return (or just leaves the box?), jump to the line.  Treat negative numbers as from the end.  Do the same with col.  Have AltG jump to the box.

Second: use the remaining space to add a Find [         ] label and box for simple search, with default settings.  This should cover about half of use cases.  Add a button for advanced usages.  The advanced box could combine the existig boxed to cover, find, replace, and multiple files.

I'm attaching mainwin3.patch, which is a subset of the previous patches, modified to not use ttk. It gets rid of the highlightthickness, the sunken line/column effect, and adds a thin separator below the text widget.

Oh, I were wrong. 8.4 still is supported in 3.5. The support of 8.3 was dropped.

Sounds like this one should be ready to review and incorporate.  

As a reminder, mainwin3.patch, which should work on Tk 8.4+, gets rid of the highlightthickness around the text widget in the editor, the sunken line/column effect in the status bar, and adds a thin separator below the text widget in the editor.

New changeset ff31af003c35 by Terry Jan Reedy in branch '2.7':
Issue #24750: Improve appearance of IDLE editor window status bar.
https://hg.python.org/cpython/rev/ff31af003c35

New changeset ecb74f61a5d4 by Terry Jan Reedy in branch '3.4':
Issue #24750: Improve appearance of IDLE editor window status bar.
https://hg.python.org/cpython/rev/ecb74f61a5d4

New changeset 483a5cd9f975 by Terry Jan Reedy in branch '2.7':
Issue #24750: whitespace
https://hg.python.org/cpython/rev/483a5cd9f975

New changeset 38d9ffbb595b by Terry Jan Reedy in branch '3.4':
Issue #24750: whitespace
https://hg.python.org/cpython/rev/38d9ffbb595b

Leaving open for now for scrollbar upgrade.

Revised plan: use ttk in 3.6 and only 3.6.  I will revise scroll patch for new file names, retest, and apply if good.

Applied as 288e97680d84 (with # -> * typo): first ttk widgets.
Issue *24750: Switch all scrollbars in IDLE to ttk versions.
Where needed, add minimal tests to cover changes.