Where do I go to learn about replacing the default...

# compose-desktop

[v79]

Where do I go to learn about replacing the default styles in compose desktop? Ideally to get rid of that awful purple and do something a bit more platform-native?

[Kebbin]

I think that's the default style for the Material Theme, and you can override it, or create your own.

[Kebbin]

val buttonColour = ButtonDefaults.buttonColors(
    backgroundColor = Color.DarkGray,
    contentColor = Color.White)

[Kebbin]

That's how I found to create a default to use on any buttons I want different.

[Kebbin]

When you create it use this then:

Button(
    colors = buttonColour,
    onClick = {

etc...

[Filip Wiesner]

If you still want the Material Theme you can override its colors, shapes and typography.
If not, than you have to create your own theming system or use some community themes like
• compose-macos-theme
• Aurora

[Filip Wiesner]

There is no functionality of using the system default theme although it has been discussed in this channel. Try searching for it.

[Kirill Grouchnikov]

Some (long) time ago, Swing tried to create a faithful emulation of the native look-and-feel for Windows and Mac using native APIs for rendering different widgets. It really didn't go well. Just way too many changes go into the native look every year for a cross-platform toolkit to keep up with the new appearance, and also somehow continue supporting the "old" appearance on earlier versions of the system.

Not speaking for Jetbrains in any capacity here, but you can see the their apps do not do native "look" for the widgets. They use the right typography (Segoe on Windows, San Francisco on latest macOS, etc), the right integration with the tray and the system menu bar etc, but the overall look of the widgets is not native.

[v79]

Thanks all. I'm not too fussed about truly native, just less... Material design and less purple. You've given me enough info to get started on.

[Kirill Grouchnikov]

One enormously influential thing that browsers as the UI "entry" into the web, so to speak, brought into this conversation is that the overwhelming majority of users do not necessarily place the utmost importance on how close the pixels in the specific app (and for this argument let's call the more complicated websites apps) are to the pixels in other places of their computer. People want to get a task done with as little friction as possible, and as few places for making errors as possible, and move on. While some continue arguing tirelessly that native is the only way to go, that battlecry has been shown to not carry much weight beyond a small - and loud - niche of developers.

[Chris Sinco [G]]

Yes. To provide even more historical context, we (Android Studio and IntelliJ UX teams) decided in late 2018 to push towards theming in the IDE that was more OS agnostic (Darcula as the baseline basically) to have a look and feel that was more consistent with only colors changing, and also more consistency with custom themes which came on the scene in 2019, configured through JSON.

[Chris Sinco [G]]

And for maintenance reasons, as Kirill mentioned, it was becoming harder to keep up with the native OS design changes, while also ensuring all our UI worked well on native themes, which when working with Swing was challenging already to get high UI polish done for only two themes (IntelliJ Light and Darcula).

[Chris Sinco [G]]

In the end, whether the IDE looked native to the OS was less important than having a polished, consistent UI across themes and platforms.

[Chris Sinco [G]]

There is a balance though, so keeping things like native main menus, system font, file explorers/pickers, are still desirable as far as keeping things looking/feeling native to the OS.