When you need to show the same UI on different devices (desktop, mobile, OSes) and media (screen, high-dpi-screen, printer) you will come up to the need of separate style definition entity almost immediately.

Like this: "Hello, <bold blue size=16>Nana C++ Library</>" Should be just this "Hello, <em>Nana C++ Library</em>" and styles for the emphasis that can be different for each platform.

Even for the same OS and user session you will need different style systems if you want to support dark and light theming for example.

Yet having UI nailed down to pixels grids (<bold size=16>) is a path nowhere.

Not necessarily. As always with software design, there’re tradeoffs involved.

Separate styles work when the stuff you’re styling is content to consume, not rich GUI to edit/produce. For rich GUI that works well on every platform you need different structure, not just different styles.

Separate styles work when the devices are not too different. If they are very different, like PC and smartwatch, you probably need different structure even for readonly content.

There’re frameworks/design patterns, like MVVM for XAML, MVC for iOS and old-school web, where you can replace complete views while reusing the rest of the app.

Why do you need such "modern C++ GUI library" then?

Check my Sciter Notes. Screenshots of the application for each platform are on its frontpage: https://notes.sciter.com/

This application uses the same UI definitions on any platform (https://github.com/c-smile/sciter-sdk/tree/master/notes/res) and the same C++ code.

Very nice library! But you only support PCs. You have same structure, and same UX (mouse+keyboard, relatively large screen) on all of them, you only need to adjust for DPI scaling, and for window resize.

About hardcoded pixel sizes, sometimes they’re OK. Apple did that in iOS, worked well for them. When they released iPhone 4, they just doubled the DPI. And when they released iPad, they made developers replace complete views and it made sense because it was much different UX.

I’m not saying that library is good. Apple has separate UI markup language, and they have decent UI designer in XCode for that. The feature is IMO required for a modern GUI framework and it’s missing in Nana.

Also, GPU-based rendering is nice to have nowadays, see MS XAML or Google Flutter.

I once needed to create rich GUI for embedded Linux app on top of essentially raw hardware, drm, kms, gles. I’ve compiled C shared library exposing some wrappers around NanoVG API https://github.com/memononen/nanovg then implemented touchscreen input, controls, styles and animations in C# using .NET core. Worked well for my requirements.

The benefits to developers are more "trade-offs", but I think it generally is a better raw framework to work in without significant IDE-assistance to do development.

Again, I like the argument. I just feel there is more taking about it, than benefits from it. Empirically, it just falls flat.

Benevolent systems cater to the least powerful user, not the median user, and I think it's good to support benevolent systems wherever possible, because businesses are naturally biased against benevolence.

Not clear what exactly.

> with just minimal styling and/or multiple versions.

If an application has simple UI that can use predefined and quite limited set of system UI elements then you probably don't need to style anything. But this is not the case of the library we are discussing.

What I meant is that most of us don't have the same content that needs to be styled differently across different devices. Majority of the time, things are easier. As you mention, use the predefined UI elements and call it a day. It is sadly hilarious how much better that would be for most applications.

For things that do have content that wants custom styling, think games and such, you are almost certainly either inventing your own abstraction language and porting that to different targets, or just creating a new implementation for each target. Yes, some folks have tried to make uber languages where you "write once, run everywhere." Those are almost always subpar compared to "write once for everywhere you care about running."

I'll say that I do agree with the argument on its merits. However, I disagree with the argument on evidence. Statistically, the style/content divide has really just increased the complexity of the code I deal with.