wxOSX dynamic background color broken (Issue #26301)
Ryan Ogurek
ryancog created an issue (wxWidgets/wxWidgets#26301)Description
The background color for windows on macOS does not dynamically update, and instead the color is static and has an (oddly) orange tint to it.
On macOS, the background color of windows (and groups/static boxes, etc.) is dynamic by default depending on the desktop wallpaper and the window's position on the desktop.
Moving to wxWidgets v3.3.2, this behavior is no longer working. Things were last working as expected for me on v3.3.0. I see there's been lots of changes to the wxOSX port over these versions (relating to both the unfortunate macOS 26 and some iOS work). Browsing through the commit history it seems 8ada351 and 5d41b24 are potential culprits.
Platform and version information
- wxWidgets version you use: 3.3.2
- wxWidgets port you use: wxOSX
- OS and its version: macOS Sequoia 15.7.1
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
vadz left a comment (wxWidgets/wxWidgets#26301)@csomor I hope you could look at this, TIA!
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Stefan Csomor
csomor left a comment (wxWidgets/wxWidgets#26301)@ryancog in order to help me, could you please pick a sample app which shows these things the best (perhaps widgets ?) and a 3.3.2 and 3.3.0 screenshot, and give me a step-by-step instruction to arrive at the same window content. Then I'll try to preserve as much as possible without ruining the Tahoe fixes. Thanks
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Ryan Ogurek
ryancog left a comment (wxWidgets/wxWidgets#26301)Here I have the widgets demo with 3.3.2 and 3.3.0
Here's 3.3.2:
It does not change based on position or size.
And for 3.3.0, I've taken a few screenshots around my desktop. My wallpaper is predominantly blue, so there's a blue tinge on the window (and then it changes just depending on the specific are of the wallpaper, it also changes based on the window size/area of the wallpaper occluded)
image.png (view on web) image.png (view on web) image.png (view on web)And with the "Sonoma" Light Mode wallpaper:
image.png (view on web)And "Ventura" Dark Mode
image.png (view on web)On 3.3.2 it's worth noting that the multiline text control background appears correctly (this is with "Ventura" again), and is tinted, as is the title bar:
image.png (view on web)Please let me know if there's more you'd like to see.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Stefan Csomor
csomor left a comment (wxWidgets/wxWidgets#26301)@ryancog thanks. a lot, I'll do some tests, to see whether I can support this without loosing the fixes that made the changes necessary in the first place.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Stefan Csomor
csomor left a comment (wxWidgets/wxWidgets#26301)@ryancog ok, I've made the default background color being transparent, but we really have to watch out on regressions this can cause
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Ryan Ogurek
ryancog left a comment (wxWidgets/wxWidgets#26301)@csomor I can confirm that the windows appear correctly for me now.
I only have Sequoia to test, however. I guess things (at least previously) looked different on Tahoe that prompted the breaking changes originally.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Ryan Ogurek
ryancog left a comment (wxWidgets/wxWidgets#26301)@csomor I'm noticing this is still an issue for lists and text controls.
Here I have 3.3.0:
CleanShot.2026-0...@2x.png (view on web)And here is 3.3.3, your branch:
CleanShot.2026-0...@2x.png (view on web)The single-line text controls have dynamic color on 3.3.0, but do not even with the changes.
Additionally, the log list has some weirdness going on. When it's cleared (with the "Clear log" button) it's fully static/"opaque" (for lack of better term). However, when some text appears, it eventually regains its background. color. It seems to take a few entries though. You can see in the screenshot some of the earlier entries still show as the non-tinted color.
Playing with the Listbox tab in the widgets demo, the static color extends over the background the height of the visible area, so if enough items are added that you can scroll down, you can see the tinted background.
It also looks like the multiline text control has an opaque background on both 3.3.0 and 3.3.2 (or your branch). It doesn't seem like this is correct either. If the control is set to single-line mode with multiple lines (which macOS is uniquely permissive with), the text control appears with a tinted background:
CleanShot.2026-0...@2x.png (view on web)Similar issue with search ctrl:
In this case the non-tinted background extends beyond the usual control boundaries and results in hard corners also.
3.3.0:
CleanShot.2026-0...@2x.png (view on web)
3.3.3:
CleanShot.2026-0...@2x.png (view on web)
Of course, the text portion of a couple other controls is affected (in 3.3.3 only):
- SpinCtrl
- BitmapComboBox and OwnerDrawnComboBox
Most of the generic controls have this issue, but also have it in 3.3.0:
- DatePicker
- DirCtrl
- EditableListbox
- FileCtrl
- Header (unusually dark, also, not the same color as the others)
- Listbook selection area
- TimePicker
TreeCtrl also belongs in that list, afaics. These are probably because the background is explicitly drawn opaque with some color, and is probably a separate issue?
This is just going through the widgets sample.
I guess I'll let you triage that... I don't think I know enough to say any more.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Ryan Ogurek
ryancog left a comment (wxWidgets/wxWidgets#26301)I'm willing to do work on this, but I'm busy in the near future and not very familiar with what's going on with Tahoe that's being worked around. Without a Tahoe install to test I'm not sure I'm very useful. :/
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Stefan Csomor
csomor left a comment (wxWidgets/wxWidgets#26301)@ryancog Thanks a lot for this, perhaps I'll have to tweak another property as well ... I'll look into this.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Ryan Ogurek
ryancog left a comment (wxWidgets/wxWidgets#26301)@csomor Been working on a wxWidgets master branch w/ your changes in the PR branch cherrypicked, and I notice that, in addition to the text ctrls and others I noted, looks like setting DoLayoutAdaptation() on a Dialog will cause its background to be opaque where it was otherwise correct.
Mostly noting it here as a reminder to myself, and maybe if there's any clue you have with more experience than I. I'll have to look into it closer, but the only thing that immediately stands out is the wxScrolledWindow that wxStandardDialogLayoutAdapter creates? But there's scrolled wins used in the widgets sample and it's not an issue there, so probably something else.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
Stefan Csomor
csomor left a comment (wxWidgets/wxWidgets#26301)@ryancog thanks, for these additional examples, yes, getting this to work without producing more visible glitches will not be easy
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.