Placeholder for improvements to the syntax highlighting tab in IDLE config dialog.

I've attached cfg_highlight.png which shows a before and after I'm suggesting as a starting point. It would have the same functionality but uses a lot less pieces to implement it. Thoughts?

I find the new arrangement more confusing.

I would make theme element chooser a list box and move the sample to the right.

One of the other options I was playing with previously was a listbox for choosing the theme (what I'd suspect is the main user activity here).

cfg_highlight_alt.png shows with the listbox for choosing a theme

Also added highlight3.png... same kind of thing, but by renaming the tab as 'Themes' you no longer even need the row of labels at the top. And it parallels the fonts/tabs design suggestion somewhat too.

After I added a custom Terry theme, my main activity has been tweaking it. Version 3 is an clear improvement over the existing tab.  With the example box on top, I think the comment should be
# Click here or dropbox
# below to change item.

0 Foregound 0 Background are supposed to be radio buttons.  The black and white squares look like anything but.

'Theme' is ambiguous as to Idle's text highlighting themes versus ttk's widget style themes. I think the current grouping should be labeled 'Text Highlighting'.  This will pave the way to add, to the ttk version, a 'Widget Style' listbox allowing users to choose among those available.

With these items resolved, I would be inclined to apply a tk patch to all versions.

The squares next to foreground/background are placeholders for those controls I can't remember what they're called (colour wells?) where it shows the current colour, and clicking it brings up a colour picker allowing you to change. So separate ones for foreground/background rather than a radio button to say what you'll set and then a button to set it. Sorry for the confusion.

Any reason that you'd want to actually include a choice of ttk themes? Not sure that would really add anything positive to the overall UX (especially on Mac and Windows).

Worth discussing more about the name 'theme' (which seems to be common in other code editors) vs. 'text highlighting' vs. other alternatives.

Btw, is there a way to change the background colour and/or has that topic come up before?

As I think I said elsewhere, I want myself and others to be able to select among the style themes provided with ttk, as well as any other themes (a dark theme?) that we or users devise.  A custom theme would be a good project for a UI design class.

I do not understand the background color question.

I am admittedly not a fan of skinnable user interfaces, especially for non-entertainment applications. It doesn't add anything to the usability, and makes support harder. It always says to me "hello, 2002 called and wants it's user interface back". I think the actual changing themes part of ttk is the least useful piece.

However, I've no grand objection to adding a setting in the general pane for this, perhaps called "User Interface Skin". 

I'm still very fond of "themes" for the syntax coloring tab. The two most commonly used terms seem to be "themes" (e.g. TextMate, Eclipse), and "color schemes" (e.g. Sublime, UltraEdit).

On the matter of changing background color, what I mean is that to modify the background color so that e.g. it's off-white instead of white, you need to change I think it's nine different theme elements.

So you mean text background as opposed to widget background.  I changed the background of non-user-entered shell, stdout, and stderr text in my personal highlight theme to light versions of the foreground, and like the result so much I have considered proposing changing the defaults. The result in Shell is to separate user entries from prompts and output and the latter three from each other.

This leaves the 6 user-entry text items with white background. This would be helpful since most people would want all 6 backgrounds in the editor the same and it is tedious to get all 6 the same 1 at a time and even worse to experiment with different settings. The explanation might be a bit tricky, but the idea is simple enough once seen.  However, I would not want the individualized colors for non-user text altered.

It seems that you want to be able to collectively define 'background white' to an off-white that would either apply to all user-entered

Looking to get some feedback on a large chunk of new code (not yet complete), for the 'new' preferences dialog. Not so much UI things as if I've made any glaring structural errors which aren't obvious to this Python sorta-newbie.

For lack of a better place, I've attached prefs-wip.patch, which just contains code for four entirely new files (querydialog.py, tkextras.py, uifactory.py, and uipreferences.py), no changes to existing files. You should be able to run it standalone just with e.g. "python -m idlelib.uipreferences"

There's some comments at the start of uipreferences.py regarding structural changes from the code in the original configDialog.py.

Thanks!

Regarding the setting background for the multiple elements.. one possibility is that the first time in a session they change the background of an element that was same as the background, we ask if they'd like to apply that change to the other program elements that have the same background.

I hope that wouldn't be too "You seem to be writing a letter..." :-)

Attached uipreferences.py, which is a newer and more complete version of the one in prefs-wip.patch

Have added the 'apply changes to other elements with same background?' feature in my private copy. To save constantly uploading new versions on every tweak, when we're ready to evaluate/integrate, I'll pass it along.

OK, will ask before review.

Since uipreferences.py was written, in 2015, configdialog uses ttk widgets, including Notebook.  We have factored out a class for each notebook pane plus one for help sources and one for traced variables.

I have in mind something like highlight3.png and will look at the Listbox and Combobox code while experimenting with a couple of things.