It's a neat project. Write cross platform desktop apps in C. Presumably it would not have been very usable in practice in the late 1980s, because of all the OTHER system interfaces that still weren't portable, even if the windowing system was available in a portable way.
I can remember the subsequent period in which Java desktop apps were relatively common. They had cross platform UI by default. But the problem was:
1) cross platform GUIs are ugly by default, compared to fully native desktop apps, because they don't entirely replicate the affordances or the style of the platform;
2) in the Java case, it seemed heavyweight to install and sluggish compared to native apps;
Point 2 would not have applied to stdwin, as it would have produced small compiled binaries I suppose, but Point 1 would have.
So in the end, obviously web apps (and partly, Flash) took over the niche that "cross platform desktop apps" had once tried to fill, and then it was something of a dead zone until Electron, as far as I remember.
1) cross platform GUIs are ugly by default, compared to fully native desktop apps, because they don't entirely replicate the affordances or the style of the platform;
These two things don't connect. Not being identical doesn't mean ugly or only one GUI would be considered not ugly.
I remember running this on an Atari ST with MiNT as the multi-tasking kernel. It took a lot less resources from my 4MB STe than running X11 did. It was actually quite usable to compile with gcc in one window and edit (with vi, of course) in the other.
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.
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.
> 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.
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]
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.
> Toga is a Python native, OS native, cross-platform GUI toolkit. Toga consists of a library of base components with a shared interface to simplify platform-agnostic GUI development.
> Toga is available on macOS, Windows, Linux (GTK or Qt), Android, iOS, for single-page web apps, and console apps
17 comments
[ 4.8 ms ] story [ 34.4 ms ] threadEdit: Someone else wrote 1988 which I suppose makes sense, as the latest reference at the end is from 1988 too. So then Guido was 32 years old.
It says 1988 there.
I can remember the subsequent period in which Java desktop apps were relatively common. They had cross platform UI by default. But the problem was:
1) cross platform GUIs are ugly by default, compared to fully native desktop apps, because they don't entirely replicate the affordances or the style of the platform;
2) in the Java case, it seemed heavyweight to install and sluggish compared to native apps;
Point 2 would not have applied to stdwin, as it would have produced small compiled binaries I suppose, but Point 1 would have.
So in the end, obviously web apps (and partly, Flash) took over the niche that "cross platform desktop apps" had once tried to fill, and then it was something of a dead zone until Electron, as far as I remember.
These two things don't connect. Not being identical doesn't mean ugly or only one GUI would be considered not ugly.
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...
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.
Win32 + Proton/Wine? No idea.
> […] 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>
[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
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.
> Toga is a Python native, OS native, cross-platform GUI toolkit. Toga consists of a library of base components with a shared interface to simplify platform-agnostic GUI development.
> Toga is available on macOS, Windows, Linux (GTK or Qt), Android, iOS, for single-page web apps, and console apps