[red_admiral]

A portable GUI interface is a hard problem, unless you mean "a browser window without an URL bar" and your controls are HTML/CSS components.

Windows has keyboard shortcuts on buttons, but you can set per-user whether they appear underlined always or only when you hold Alt. Mac always has exactly one, immovable menu bar; and Enter doesn't close a dialog box. GNOME can rollup or pin windows from the title bar if you add the buttons for it. Whether the native dialog layout has the ok button to the left of the cancel button depends on the OS and the writing direction (p206 of [1]). Not every platform has a native calendar widget. And so on ...

Worse still, you're building an abstraction layer on top of several genuinely different systems, that users of different platforms will expect to work differently in the first place. Go down this rabbit hole and you end up with "show a help button on modal dialogs only on platforms where this is usual, and where you can open the help window without closing the modal first". "Portable native-GUI" is almost an oxymoron; wxWidgets is perhaps the closest we can get where at least you can ask for a wxFindReplaceDialog abstraction (p229 of [1]) and get the cancel button in the platform-default place, even if "Find-Replace Dialog" is not a feature included in the OS' component library itself.

[1] https://wxwidgets.org/docs/book/Cross-Platform%20GUI%20Progr...

[jon-wood]

This is all true, and if I were building a tool which I'd expect to be widely use I'd approach it as a common core with platform specific GUI layers like Ghostty (and I'm sure other applications) does.

Sometimes though you're throwing together a quick and dirty UI for a specific use case that you just want to run on a bunch of different platforms and this sort of toolkit is great for that. It can be the difference between the application existing at all and it being available on a range of operating systems.

[fernly]

HTML/CSS components were not available to Guido in 1988. It was in 1989 that Tim Berners-Lee defined the first version of HTML[0] and CSS was proposed five years later[1]. In 1988 Guido would have known about the Mac (1984) which he cites, and the X Window system, which was 5 years old.[2]

[0] https://en.wikipedia.org/wiki/HTML#Development

[1] https://en.wikipedia.org/wiki/CSS#History

[2] https://en.wikipedia.org/wiki/X_Window_System#History

[CyberDildonics]

A portable GUI interface is a hard problem, unless you mean "a browser window without an URL bar" and your controls are HTML/CSS components.

Says who? This has already been done over and over. Tk, FLTK, JUCE, Qt, ImGUI and many more.

Worse still, you're building an abstraction layer on top of several genuinely different systems,

Features are pretty common across linux windows and macos. Clipboards, input, files, all sorts of stuff works enough that the lowest common denominator still covers about 90% of use cases.

[cxr]

> A portable GUI interface is a hard problem, unless you mean "a browser window without an URL bar" and your controls are HTML/CSS components[…]

> […] an abstraction layer on top of several genuinely different systems[…]

> […] wxWidgets is perhaps the closest we can get[…]

For good reasons—because you'll likely exhaust yourself or starve of resources before you finish the project, and because it also doesn't tend to help with the readability of the codebase—it should be ingrained in all programmers to be strongly against "portability" approaches that try to make platform X work like platform Y by providing implementations of Y APIs that work on platform X. (See also yesterday's news by Wasmer about their AI-coded approach[1].) The goal is almost always better achieved by defining, up front, the minimum interface that the program needs to be able to work on the host—which forms the kind of abstraction you're talking about—and then connecting that to the actual host APIs (which usually suck to use, anyway), repeating for each platform. Almost.

Desktop UI toolkit APIs are one exception to this—which is unfortunate, because it's like the one use case where people actually try to do the opposite of the usual impulse, and we're all worse off for it.

The major desktop platforms are so few, and the APIs are so stable and so slow-moving, that it's well past the point where the cross-platform native app solution should have been adopting/implementing the platform Y APIs everywhere, where "platform Y" is Cocoa[2]. Like, at the latest, the Oracle v. Google decision in 2021 should have been the last hurdle. People get weird about this, though, and confuse APIs with implementations, or conflate Cocoa with Objective-C (and/or a mandate to program in Objective-C), or think this amounts to a claim that this means we should all be using GNUStep. It's not. It's not any of things. It's very simple: the window-and-widget APIs across all desktops should be Cocoa-shaped. That's it.

1. <https://wasmer.io/posts/edgejs-safe-nodejs-using-wasm-sandbo...>

2. <https://news.ycombinator.com/item?id=30359206>

[ogogmad]

> A portable GUI interface is a hard problem, unless you mean "a browser window without an URL bar" and your controls are HTML/CSS components.

Win32 + Proton/Wine? No idea.

[zahlman]

I'm pretty sure TFA is from before there was any widespread use of HTML for much of anything.