-
-
Notifications
You must be signed in to change notification settings - Fork 29.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix IDLE Autocomplete / Calltip Window Colors #80357
Comments
IDLE utilizes the foreground text color from KDE/Qt (Window Text) for the autocomplete and calltip windows. If a dark theme is selected and the window text changed to white or another bright color, it can be difficult or impossible to see due to lack of contrast. There does not appear to be any way to change these particular windows text or background color settings from IDLE's configuration. Modifying the variables under line 192 in autocomplete_w.py (bg="white") and line 83 in calltip_w.py (background="#ffffe0") allows these windows to change background colors. Perhaps add these as settings in IDLE's config? Or force the foreground color to always be black? Python 3.7.2 KDE Plasma Version: 5.15.2 (This is my first bug submission ever, so if I missed something obvious, I apologize in advance) |
The only thing missing is the OS, which I presume is some version and distribution of Linux. IDLE used tkinter which uses tcl/tk. From what you say, the latter, at least on Linux, picks up its default colors from the window manager, which for you happens to be KDE. (This seems not true, at least not yet, on current macOS, as switching to the new dark theme has no effect on IDLE.) This suggests that when a widget has both foreground and background settings, IDLE should leave both alone to use compatible defaults or set both. Except for text windows (which have both fore- and back-grounds) and frames and canvases (which only have background), IDLE generally does not set colors. I just verified this for the settings and search dialogs. Do these switch to light on dark when you set you screen to the same? Setting autocomplete bg to white is an anomaly from before 2005. It is useless or wrong and I think we should just delete the setting. Setting the calltip and tooltips backgrounds (tooltip.py, line 162) to yellow is intentional, to contrast with the text. So we should also set the foregrounds (to black). I don't think these need to be configurable. Cheryl, does your Ubuntu desktop have a dark theme option? If so, does it affect tk defaults and hence IDLE? |
Kristoffer, can you try removing 'bg=while' from autocomplete_w.py? |
I didn't see an issue with a Gnome, so I installed KDE Plasma and switched to the dark theme. I was able to recreate the issue for autocomplete. When I tried 'open file', I also saw it there and I've attached a screen print showing how it looks on 'open file'. Removing the 'bg=white' in autocomplete_w.py fixes the issue by changing it to a gray background with the almost white text. Of course that doesn't affect the 'open file' window. I've also attached a screen print of what the search dialog looks like. |
I presume that the folders have names I cannot see because they are white on white, even though the current directly name is black (on gray). The effect of the dark screen theme seems inconsistent. The open and save-as dialog boxes are provided by tk to either use or match the OS version. (On Windows, I am fairly sure the native widget is being used.) The tkinter wrappers are in its filedialog module. There are no color options. So this is a tkinter or more likely, tk, issue. This suggests to me that tcl/tk and KDE are not quite compatible. The search box (searchbase.py) uses ttk widgets. It seems that ttk.Frame picks up its background color from the environment while the included ttk widgets do not. The effect is a little strange, but at least the text, including the entered text is readable. We could make the backgrounds consistent either by setting the frame 'white' or by conditionally using a dark theme (there might already be one) for the contained widgets. This is a separate issue. The 3.7.3rc cutoff is in a couple of days so I will make a minimal PR to fix the overt bugs that we know about and can. |
Awesome, thanks. Let me know if there is anything you'd like me to test, it looks like On Sat, Mar 9, 2019, 20:35 Terry J. Reedy <report@bugs.python.org> wrote:
|
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: