Master issue for theming and styling

[andlabs]

Very common request, in particular on the Go side.

Not sure if I want to support full theming, especially since every OS has a different way to do it, and I'm personally not sure how I feel about that.

Overriding some aspects of appearance for individual controls might be a different story, but IDK.

[mischnic]

Also came up often with proton-native:
kusti8/proton-native#11
kusti8/proton-native#51
kusti8/proton-native#64

[adamierymenko]

I think it would be okay to offer a convenient way to expose each OS's theming / styling settings and then say "you're going to have to style this per-platform if you want styling." Just styling per platform is a lot less work than implementing 100% of UI logic per platform.

This way you can develop once and then style many times vs. developing many times using different UI programming paradigms.

With libs like Qt that try to abstract styling you still usually end up having per-platform style sheets.

[andlabs]

For the record, CSS theming would require implementing a CSS parser on Windows and macOS, and CSS layout would also require a CSS layout parser on GTK+, as layout is still done outside of CSS there. Having one CSS provide both themes and layout in that case would be an interesting problem.

[phpfs]

Am I right in the assumption that there's currently no way to change a label's text size?
If this is the case, simple styling would be absolutely needed to even create the most basic UIs...
I personally really like this library as it can be compiled to a simple .exe on windows or to an .app on macOS without complicated build enviroments :)

So thank you for this :)

[mischnic]

Am I right in the assumption that there's currently no way to change a label's text size?

You could create an area and use the attributed string api, but the main problem for label usage is that you cannot define a minimum size for the area.

[teratorn]

Possible to use the Servo CSS style engine from Mozilla?

that's rust code... maybe that involves depending on too many moving parts for humble C developers - i wouldn't want to depend on some huge CSS style engine in C or C++ personally, and doing it /all/ yourself doesn't sound too fun.

[Merlinstail]

I oppose theming a simple reason. The native controls already have theming provided by their respective systems.

libui fits neatly into a long unoccupied space where a simple lightweight library with native controls is the goal. It would be a shame to spoil it with bloat, especially at the expense of progress and stability. Perhaps this should be made clear in the Readme.md.

It should be for a developer to choose a UI library that suits their needs instead of forcing the library to bend to their design aspirations. Accordingly if custom look is required they should choose a library that is designed for that purpose, there are many available.

[rubyFeedback]

libui fits neatly into a long unoccupied space where a simple lightweight library with native controls is the goal.

I do not disagree on libui's use case being small. I disagree that being unable to easily choose e. g. font size is a good thing. I need larger fonts for an elderly relative. The easier it is to customize things here the better.

CSS support may not be necessary, neither theming. But being able to change such basic aspects should be possible. Even Java Swing allows for that and barely anyone uses it these days.