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.
I think this is an implementation detail. It's up to the software stack whether it leaves off before drawing the UI elements on screen, or goes ahead and takes on that responsibility too. The wxWidgets toolkit uses the runtime platform's UI, so it does not draw the widgets themselves. Java Swing took on the task of drawing the UI elements on the screen in its own style.
Basically, cross-platform GUI only looks good on the platform that it was originally designed for. Unless the other platforms make zero interesting choices, they will always look worse.
Sun/Oracle also cheaped out by not having designers. If you see Flutter, they are able to recreate all of the platform specific widgets purely by having design engineers eyeball the implementations until they replicate the exact color and timing of every animation. Oracle/Sun was cheap and lazy.
I saw a screenshot of GTK 1 and the first thing I thought is that I'd rather make something using GTK 1 than GTK 3. Unfortunately I asked an AI chatbot about it and they advised against it because of "security" :(
So if I run Dune2 in dosbox, is that a security issue? Of course not, but if you were to load a bitmap from the network and feed it to GTK1 for displaying, there could well be an overlooked issue lurking around. But you need to look at the greater picture, not just "old==insecure"
These two things don't connect. Not being identical doesn't mean ugly or only one GUI would be considered not ugly.
https://en.wikipedia.org/wiki/Tk_(software)
...which even leaked into other language ecosystems like Python:
... was said reading it in a browser on who knows what OS/DWM.
I mean that 90% (if not more) of all UI interactions happen now in a browser or in multi-platform applications (e.g. messengers, SublimeText, VSCode, etc).
It says 1988 there.
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.
[0] https://en.wikipedia.org/wiki/HTML#Development
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.
> […] 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...>
Win32 + Proton/Wine? No idea.
Edit: 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.
> 32 years old
As a ~20 year old this feels so weird to read. I'm still considered young in ~10 years?
Back when I was a teenager, people in their 20s were “old farts.”
Nowadays, I look at people in their 40s, as “kids.”
Here’s my first ever engineering project (1987): https://littlegreenviper.com/wp-content/uploads/2022/07/TF30...
I was 25, at the time, and a fairly newly-minted EE.
An anecdote for you...
In Summer 1997 i was 24 at a family reunion, listening to my grandmother and several other seniors talk about some recent interaction my grandmother had had with a delivery person. One of her friends asked her, "how old was he?"
i'll never forget either her response or my jaw-dropping which followed:
"Oh, he was a _young_ man. About 50, I guess."
(Yes, she actually stressed the word _young_.)
One of these days, maybe as early as your mid-/late-40s, you will be consulting with your a medical doctor and realize that you are the oldest person in the room.
You'll still feel young too! It's really weird when you get to your mid 30's and realise that all the 20-somethings view you as old
> 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
