-
-
Notifications
You must be signed in to change notification settings - Fork 30.8k
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
IDLE: use ttk.Frame for ttk widgets #78168
Comments
When adding a bunch of ttk widgets into a toplevel window, there needs to be an intervening ttk.Frame to ensure the background of the widgets matches the overall background. The reason is the 'toplevel' is part of the classic tk widgets and not ttk, so it isn't guaranteed to have the same background. In practice, the only platform where the toplevel and ttk.Frame have different backgrounds is macOS. Check out topframe.png for an example, top is without the intervening ttk.Frame, bottom adds it in. (Adding bug mainly so we have a place to store a concrete example of what this looks like) |
The image could have been attached to bpo-27477, but a new issue for a new PR is needed anyway. I will make this a dependency of that issue. I did not at first see the difference in the screen-capture images on my monitor in Firefox with the room lighting and my eye condition as it was then, but today I do. On Mac, the defaulf ttk background is slightly darker than the default tk background. (No so on Windows.) It looks subtlely tacky. I imagine this effect might be more obvious and annoying on the live screen. As I mentioned elsewhere, this is a second reason to insert a frame inside Toplevel, but it is a reason to do this *now*. Please submit a PR for this addition to searchbase: a new ttk Frame, with a bit of space added. Please call it self.frame as in query or perhaps self.searchframe, analogous to viewframe in textview. When SearchDialogBase is renamed SearchFrameBase(Frame) and the toplevel stuff moved to another class, self.???frame in the Frame subclass will become self, so the name will only appear in the toplevel class. In test_searchbase.SearchDialogBaseTest.test_open_and_close, adding configdialog needs a similar PR. config_key needs a complete ttk conversion. |
The change is trivial and there was already a Frame test, which initially failed. I will open another issue about similar changes needed elsewhere. |
We don't really need a new issue. Mark's opening post was generic. I grepped for ttk to get existing ttk imports and am making Frame and LabelFrame the first item or items for each import. I won't worry about whether any background is visible, as this could change. Cheryl, please note the import convention and review the diff when posted. |
I closed this prematurely. Cheryl's PR 11433 converts frames for help and statusbar. My patch also omitted searchbase, perhaps because this I wanted to refactor at the same time. In any case, the macOS appearance bug that motivated Mark's post remains, and a patch will have to make sure that the derived dialogs add frames inside the new master frame instead of the toplevel. The message I deleted meant to say |
Thanks for hopefully finishing this issue. |
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: