Idle sets *some* colors to hardcoded values and uses the system defaults for other colors. This is extremely bad when you use a dark gtk color scheme and now a almost white text (system text color) is displayed on a white background (idle tooltip background color).

There are two solutions to the problem: Also set the foreground color to a hardcoded value or better detect whether the foreground color is bright or dark and choose an appropriate background color. I've implemented the latter for the idle that comes with fedora 12 (2.6.2). I forgot to backup the original files so I can't make a diff/patch. However, I attached the changed files and here is a summary of my changes:

in idlelib/ToolTip.py:
added functions:
parse_color(color)
set_tooltip_bg(widget)

in ToolTipBase.showcontents():
set_tooltip_bg(label)

in ListboxToolTip.showcontents():
set_tooltip_bg(listbox)

in idlelib/AutoCompleteWindow.py:
added:
from ToolTip import set_tooltip_bg

in AutoCompleteWindow.show_window():
set_tooltip_bg(listbox)

in idlelib/CallTipWindow.py:
added:
from ToolTip import set_tooltip_bg

in CallTip.showtip():
set_tooltip_bg(self.label)

I just noticed that the debugger also suffers from this problem. Doing a quick grep over the source reveals even more places that might cause problems (where only the bg or only the fg color is set).

I think in ScrolledList.py the background="white" should just be removed. This and setting the fg color to black when the bg color is set to yellow (Debugger.py) makes the debugger usable.

Checkboxes and radiobuttons seem to be messed up in general (forced white bg but using system fg color (white on white on my system); not IDLE's but Tkinter's or TK's fault).

I just found out the right method to parse a color in tk, so I removed my parse_color(color) function.

Sorry, I uploaded the wrong archive.

In ToolTip.py I removed my parse_color(color) function, in Debugger.py I set the fg color to black when the bg color is set to yellow and in ScrolledList.py I removed brackground="white".

I need more sleep. I seem to have forgotten to attach the file

Updated the issue to reflect information from 16984. A screenshot was provided in that report.

bpo-16984 is closed as a duplicate of this. The screenshot helps. I was just thinking about adding a retro-black color theme to match the current old-is-new fashion. It appears that this would solve the Text part of the problem but Mathias' patch summary shows that more is needed to get other widgets in line.

It appears that a review and written summary of colors in Idle would be helpful. I am curious what effect switching to themed widgets would have on this issue.

Problem as I understand it: various tk widgets and Idle popups and dialogs mix, for instance, a hard-coded background (white) with a sometimes incompatible (no or low contrast) system-default foreground, which is also white when the system background is black. Hence the sad screenshot for bpo-16984: https://bugs.python.org/file28755/snapshot-idle.png.

Some of this may be tk's fault for not anticipating reversed graphics screen, some may be Idle's (I doubt tkinter gets involved). In any case, a solution is for Idle to set the colors for *every* widget it creates. The colors could be fixed in particular cases, but we could instead use one of the currently 13 user settings*. bpo-24820 is about adding a light on dark theme to Idle. When we start using ttk widgets (within a month), I believe this will be possible by setting an explicit default color pair for each class.

• I am thinking I might try using the new dark theme on my white-background system, but I cannot know that I would want all the dialogs to use it. We might want to allow separate tagged text themes (what the current highlights are for) and widget themes. This will take some experimentation.

Use of ttk got delayed for back-compatibility issues. We should be clear to start in a week.

The IDLE Dark theme has been added and I use it routinely. Ttk widgets, including frames, are AFAIK used everywhere possible. We are not yet using ttk styles to configurable colors, but I would expect that the default style should always be viewable. My speculation is that this should prevent white-on-white or black-on-black.

Mathias and Sureyya, do you see today the unusable combinations you say 10 and 7 years ago?

Cheryl, are any of the issues described above possible on Ubuntu (today)?

I believe this was fixed with #80357.

Thanks for finding that. Technically, #80357 should have been closed as a duplicate of this issue. But a fix anywhere is OK. Any other contrast problems should be a new issue.