Hacker News Reader

Comment by tmtvl | Hacker News Reader

Uses SDL for rendering the UI. While it makes it work cross-platform it unfortunately means it won't look like a native application. Then again, I don't think there's a C library which provides cross-platform native UI, only the Lazarus toolkit for Free Pascal and WxWidgets for C++.

View on HN

"Native" means compiled code (likely C/C++/Rust/Zig) for some. And it means using platform-specific UI widget for others.

I don't care too much about the UI widget style as long as the implementation is good and responsive. I tend to use app in fullscreen (F11) with minimal chrome and to be honest I kind of like when each app has its own UI style, especially if it can be user-configured with themes.

Apple/macOS users tend to fall in the other category, following the Apple guidance, where all apps should look like they were made by the same company.

> following the Apple guidance, where all apps should look like they were made by the same company

Mac users don't want all GUI apps to look alike; however, they should follow macOS UI/UX guidelines regarding copy/paste, drag and drop, keyboard conventions, etc. The whole point is to not have users having to relearn these basics for every new application.

Developers generally get these conventions "for free" by using the frameworks built-in to macOS. That doesn't prevent developers from creating custom, stylized interfaces if that's what's needed.

Even Apple's pro apps (Final Cut, Logic, etc.) look quite different from those that are bundled with macOS such as iMovie and Garageband.

I wonder if people actually remember how native apps are supposed to look like on any of the major platforms… Mac users, maybe. For all other platforms, churn and barely contained web apps are really wreaking havoc on the benefit of a uniform look and – most importantly – feel.

I'm a KDE user who really likes the classic Oxygen theme, and it's annoying when certain applications (e.g. Eclipse) just look way out of place. I managed to find a decent GTK port of the theme so even Emacs and Firefox are quite well-behaved.

No idea what a Windows app looks like, though, I recently fixed my grandfather's Windows 8 laptop and immediately gave up trying to understand how theming is meant to work.

(As another KDE user) I'll second this. Electron-based apps seems to be the worst culprits -- ignore my preference settings for max/min/close buttons, frequently do away with the title bar altogether leaving me with no window resize/move and hiding away Application/Window settings options, no regard for themeing,... it's become a significant (read: near deal-breaker) for me trying out new apps.

The massive changes in native UIs look and feel over the last couple decades really has made me double down on the CLI as the best interface. The CLI and the terminal are well established UIs with no big changes in a long time. The last big development I can think of is the use of sub-commands in addition to the normal command line call parameters.

I now focus on making my shell/terminal environment as good as possible and ignore GUI land whenever possible. Which today pretty much means 99% of the time I'm running a bunch of terminals and a couple web browsers.

Visually it's not that different, of course, but I don't see a more unified interface in the terminal these days. The Amiga might have had it, with its TRIPOS arg parsing, and of course you got your language-integrated text UIs like Oberon.

But beyond that, it's a mirror of the graphical side. I mean, it's not like the GUI invented a lot of new widgets, either. There are still buttons and menus, it's just that they look and behave differently in each app. The same goes for the CLIs, where there's no rhyme or reason for all the long/short parameters, sub-commands etc.; To use the git metaphor, we're in a bathroom where all the porcelain is coming from different manufacturers and your got your brutalist toilet bowl next to your gold plated sink. And nobody knows what to do with the three shells.

> Then again, I don't think there's a C library which provides cross-platform native UI, only the Lazarus toolkit for Free Pascal and WxWidgets for C++.

libui seemed like it was going to be this, but it looks like there haven't been commits in almost 2 years :(

(I'm mostly replying to raise visibility on libui, maybe someone will discover it/help out a bit)

There's now libui-ng [1] which seems to be active and already has many wrappers

[1] https://libui-ng.github.io/libui-ng/

Native UIs are becoming an anachronism pretty fast. Free-form web and electron based apps are becoming the norm and it won't be to long before people see native UI apps as some sort of weird throwback.

IE. IMO that ship has sailed and using lower level/cross platform graphics stacks make a lot more sense these days.

Fast native running binaries will never be anachronistic

I'm not saying they won't still be around. They will just use lower level graphics libraries and be more free form. The days of the 'native' GUI widgets are over.

you might be right, even though I find it very depressing. Native UIs using stock elements in simple ways tends to create competent interfaces. Web and electron apps are often confusing bespoke messes.

Native-ish interfaces are still pretty prevalent on mobile though.

"cross platform graphics stacks make a lot more sense"

Oh how they laughed when Sun tried this with Java some 25 years ago...

So, is it actually small or is it just small on top of large libraries which do the heavy-lifting? I mean, ok, not Electron, but an Electron-based editor could also claim it was "small".

Reply on news.ycombinator.com