Repository navigation
IDLE: use ttk.Frame for ttk widgets #78168
Description
Activity
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)
- addedtype-featureA feature request or enhancementA feature request or enhancement
on Jun 28, 2018 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
self.assertEqual(self.dialog.frame.state(), 'normal')
will test the change, failing now, passing with it. I don't know of any other changes needed in files other than searchbase.configdialog needs a similar PR. config_key needs a complete ttk conversion.
- changed the title
[-]need ttk.Frame inside Toplevel(s)[/-][+]IDLE: add ttk.Frame inside searchbaseToplevel[/+]on Jun 30, 2018 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.
- changed the title
[-]IDLE: add ttk.Frame inside searchbaseToplevel[/-][+]IDLE: use ttk.Frame for ttk widgets[/+]on Dec 31, 2018 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
bpo-35598 converted config_key to ttk, including a ttk frame inside toplevel.4 remaining items
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: