On macOS 26 Tahoe, just the mere presence of drawRect:
in class derived from NSTabView
prevents native appearance rendering and triggers legacy appearance code path.
Before:
before.png (view on web)
After:
after.png (view on web)
Apple Mail:
apple_mail.png (view on web)
This isn't caused by wx's handling of drawRect:
, but really by just its presence. Even applying this change and adding a minimal
- (void)drawRect:(NSRect)dirtyRect { [super drawRect:dirtyRect]; }
to wxNSTabView
reintroduces the bad rendering. In other words, there's nothing else to be done other than using wxOSXSKIP_DRAW
.
Out of abundance of caution, I made this conditional on running on macOS 26 (and being compiled with Xcode version aware of it), so that it doesn't break customized rendering on the off chance that somebody does it. But AFAIK the official position is that customizing native controls like that may or may not work, and so may be better to just do it unconditionally (or perhaps conditionally on the 3.2 branch only)...?
P.S. This is probably related to internal implementation changes to share code with SwiftUI and risks being a problem in other controls too. See https://mastodon.social/@macmade/114670766027908350
https://github.com/wxWidgets/wxWidgets/pull/25743
(1 file)
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
@vadz approved this pull request.
Thanks for fixing this, I'm not qualified to really review it, but considering what you say, this seems like the only thing to do. And I agree that we never really claimed to support drawing over the native controls, even if it could work sometimes, so I don't even know if it's worth mentioning that it doesn't work in this specific case in the docs.
So let's merge this — unless Stefan knows of some miraculous way to make this work, of course.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
@vslavik thanks for this. @vadz I don't know of a better way. That's the reason I've added these flags, we loose our internal ability to hook into events, but we gain the 'native' advantage, since macOS often uses either SDK version linkage or method tables lookup to decide whether to activate some kind of backward-compatibility.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.