You can try pursuing it, but it is a field littered with the dead project before you that have tried the same thing. Xamarin, Flutter, Qt, React Native, the list goes on. Some of these projects are mostly-dead, others are heavily used but no user is actually fooled.
I would propose something different: for Java to develop their own design language, which has "good enough" native platform integration but otherwise doesn't try to pretend. Cross-platform platform users generally belong into two camps:
- Ok with something that appears visibly different from true native apps, but the cost savings are worth it and the users don't care so much about native-feeling-ness.
- Under the expectation that their cross-platform app will be so good that it is totally indistinguishable from a true platform-native app.
My contention is that Java (and other xplat projects) should focus on the first group; the second group is not worth serving because it has always failed, and will always fail.
The problem with the state of Java GUI development isn't so much that it fails to emulate the native platform GUI sufficiently, it's that it's ugly and janky. Improving it should be the goal.
JavaFX is not that?
Exactly this -- every cross platform GUI toolkit ends up falling into an uncanny valley where it looks sort of native but subtle things are just off.
This is, I think, a key part of Electron's popularity. Apps made with Electron are so very obviously non-native that they avoid this uncanny valley effect.
It's better to have one developer per platform, than two (or more!) working on a cross-platform application. And you get true native applications; think of things like accessibility options, which are often overlooked in cross-platform toolkits, or performance.
Sorry, but the problems you are talking about are first-world problems imho. If the button looks like a button, and clicks like a button, what is the problem really?
it happened all the time when almost all of the graphic designers (which were thrust into the roles of UI designers) were on mac and usually ios but got the task of "designing an app", which meant _one_ design for both ios and android. as an android developer i had to fight the OS, the framework and pretty much everything else to make the designers vision work, which resulted in buggy apps that felt unintuitive to use.
E.g. visit https://twitter.com/ and select Sign-up. I don't know what OS you are on, but the sign-up box probably doesn't look native. Users accept this. So what is the problem, really?
platform design choices are much more than the look of a button. it's choice and arrangement of ui elements, navigation systems, metaphors, ...
if you just see it as "button on windows" vs. "button on macos" it's not that obvious, but think about how you'd design an email client on windows vs. command line vs. mobile phone vs. smart watch.
a simple "button" might be roughly the same on every platform, but the overall design would be quite different.
It used to be so consistent and poweruser friendly.
Windows 11 has just broken a lot of the poweruser keyboard shortcuts for doing things, on top of all their ads, nagware, telemetry/stalking and various antifeatures, it's like they are begging power users to go to Linux.
Yes, I’ve long thought this as well.
I think it’ll take an entirely different approach than cross platform UI libraries typically take — rather than implementing widgets itself, it would have the developer provide a somewhat loose “UI spec” document that then gets compiled into a UI befitting each target platform. Not only widget appearances and behaviors would vary between platforms, but also window layouts. The only exception to the rule of not implementing widgets itself would be where one platform lacks a widget to avoid least common denominator problems (for example, WinUI and GTK have nothing resembling Cocoa’s miller column NSBrowser control, so those platforms would get an implementation of that view built from other native controls).
It wouldn’t fit every use case since it wouldn’t provide down-to-the-pixel control but it would work for a lot of software.
SWT (the UI library which drives Eclipse) would give you that on Windows, OSX and Linux. But it's not exactly light-weight...
Then after that maybe add a cross-platform toolkit that doesn't try to look or feel local, but treat that as a peer with the other UI kits, not a replacement.
Different OSs have different norms, expectations and design languages.
What I'd like to see is something that abstracts as much as it can but still allows you to make something look like a native app on that platform. That would mean you'd need to do some programming for each platform but honestly I don't think there's a good way around that.
The solution isn't Electron. Way too heavyweight. Wayy too resource intensive. Way too risky by having a huge attack surface.
An additiojnal problem with Java is bundling such an app. Requiring a JRE on a target platfrom is (IMHO) a big problem. They're far from universal now. Something that compiles to a static binary. There have been efforts to create self-contained standalone packaging for Java applications. My understanding (which may be incorrect) is that all of these solutions are still somewhat suboptimal.