I’d like to refine the original idea based on the feedback in this discussion.
Instead of creating a separate set of "NativeButton", "NativeInput", "NativeDialog", etc., I think this could fit better into the existing "Theme" system.
The goal is to allow the existing "gpui-component" components to automatically feel native to the platform they are running on.
For example:
Button::new("Save")
could use an appropriate macOS/Cupertino-style presentation on macOS and Fluent/Windows-style presentation on Windows, without requiring developers to maintain separate platform-specific components.
This could cover more than colors, including:
- Typography and spacing
- Control sizes and corner radii
- Focus, hover and pressed states
- Menus, dialogs and toolbars
- Keyboard shortcuts and platform conventions
- Accessibility and interaction behavior
The important distinction is that I don't mean wrapping actual AppKit or WinUI widgets. The components could remain GPUI-rendered while following the conventions of the host platform.
I also agree that prefixing every component with "Native" isn't ideal. The existing component API should remain unchanged, with the platform-adaptive behavior provided through the theme/platform layer.
Why this could be useful
This could give GPUI Kit a simple way to build applications that:
- Use one cross-platform component API
- Automatically adapt to macOS and Windows conventions
- Avoid duplicated platform-specific components
- Still allow developers to customize or use the existing themes when they want a consistent design across platforms
I think it would be interesting to explore whether the existing "Theme" system can support this cleanly, rather than introducing another parallel component library.
Would this be a direction worth considering for "gpui-component"?
Activity
3
fazi-gondal1mo agoHi @martenio thanks, I think you’re right about the component duplication and the "Native*" naming.
I’ve reconsidered the original proposal and I’m happy to change the approach completely. Instead of introducing a separate "gpui-native" component set, the idea could be to extend the existing "Theme" system so the current components can adapt to the host platform.
For example, the same "Button", "Input", "Dialog", etc. could use macOS/Cupertino conventions on macOS and Fluent/Windows conventions on Windows.
I think that fits the existing architecture much better and keeps the API clean.
The main question I’d be interested in exploring is whether "Theme" alone is enough for this, or whether some platform-specific interaction/keyboard/accessibility behavior should live in a small platform layer alongside it.
I’ve updated the issue to reflect this revised direction. Thanks for pointing this out.
huacnlee1mo agoThanks for the thoughtful proposal. GPUI Kit aims to provide a consistent cross-platform design rather than reproduce macOS or Windows controls and behavior. Matching either platform faithfully would require much more than theme tokens, and a partial imitation is unlikely to feel truly native. This isn't a direction we plan to pursue in GPUI Kit. Applications can still customize their themes and interactions for their own needs.
Just make a
Themefor it, the rest of the interactions should already be "native". You are duplicating all components for theTheme, while you could just useTheme. Also I wouldn't like having to prefix all components withNative.