Using the widget set provided by the platform is not easy, and that's not what druid tries to do. Rather, there's a platform abstraction layer (druid-shell) that takes care of all this stuff for you, and has all that nasty unsafe code in it, then it draws its own widgets. We try to feel more "native" in that we're using platform menus and so on. It's certainly possible to be more native (calling into Cocoa widgets) or less (using Web technology), but I think what we're doing is a good pragmatic approach.
Of course, things have gotten a bit postmodern, even on macOS there is no single widget toolkit, but basically a series of choices of what technology to build on. I'm actually not sure that binding other languages to SwiftUI is going to work well at all, but in Objective-C it works fine, just isn't very smooth. On Windows, I've generally found COM to be quite pleasant, and noises coming from Microsoft suggest that story will become even better.
I have never seen this go well in practice :( Qt and Flutter do this and the experience is just…not great. Do you have any ideas on how to do better than them if you're using this approach?
To be clear, we're focusing on the use case of a font editor, where you're mostly interacting with highly custom views, much less so with layouts composed of stock widgets.
As I said elsewhere, increasingly we're in a world where there isn't a standard set of platform UI widgets. I think that was the case when we had Cocoa on macOS, but on Windows it's a choice between MFC, WinForms, WPF, WinUI, and those are only some of the choices offered by Microsoft itself.
It's a good question, though. It's possible somebody will figure out a good way to abstract over officially supported platform UI toolkits, and if so, that might become a compelling choice. This is one reason why the main point of my blog is that we need to figure out the best approach, rather than just assuming we know what to build.
MFC and WinForms both just abstractions over Win32. WPF was clearly targeting being indistinguishable from the old widgets and had a much better success rate than other reimplementation attempts. It's really only with UWP/WinUI that you'd notice the difference without going searching and that has received a lot of consequent complaints.
Paint.NET is the one app I've used extensively that I'm aware of being a WPF app, and that's because I remember reading a dev blog about implementing aero glass when 4.0 was being developed.
There are some advantages to this approach that often go unmentioned. Native widgets often have ad-hoc limitations based on their legacy, for example limits on composing/nesting widgets (can a list box contain a list of arbitrary widgets?) and system resource limits (e.g. windows handles). Attempting to build a cross-platform UI that maps to different legacy systems each with their own quirks and limitations, will never produce something better than QT or Flutter IMHO.
You’re right, I think this is the first time I’ve heard someone mention this. I was actually quite surprised when SwiftUI came out because in Cocoa/Cocoa Touch there is a clear set of things you “can” do and everything else would just break and the new declarative language allows (and even encourages) very strange combinations. I haven’t used it a whole lot, but it seems like they’ve done a pretty good job making it mostly work.
Would it make sense for Rust to have UI primitives that are named the same as SwiftUI's?
e.g. Text, HStack, VStack, ZStack, List, ForEach, Button(action, label)
Even if they don't output the same widgets on all OSes, I think just having a shared convention might be a good first step towards learn-once/write-native-everywhere crossplatform UI.
That would kinda suck for everyone who's used to wpf, qt, swing, gtk+, etc, bootstrap, whatever came before wpf, (winforms? Don't remember) etc etc. "Just copy whatever Apple does" seems like the worst possible solution for a cross platform widget naming convention out of many possible bad solutions.
Naming stuff matters a lot less, (but still sucks) but if you pick UI system and copy all its primatives, you're guaranteed to end up with a bunch of widgets that really, really suck in several native widget sets.
Ultimately, there's not a good way to do cross platform UI. It's always going to either be mediocre on all platforms, or really bad on every platform except one. At best, it will be ok for a while, and then one platform will redefine what "native" looks like and now all of the tradeoffs you've made so that it's mostly ok are just technical debt.
I don't mean to piss on anyone's parade, but cross platform UI is probably the hardest problem in software engineering. There have been a dozen or so teams of people smarter than us who have tried and failed.
If it were my job to make a cross platform UI system for rust, I'd quit and get a job where I wasn't set up to fail. If there was a gun to my head, I'd write a fairly thin wrapper around Qt. The idea being that most people already have 1-3 Qt programs they use regularly. So even though it looks like a Qt application instead of a native one they'd still be familiar with it and it wouldn't look out of place. Then I'd spend most of my time engaged in politics. Install a few developers to developed Qt whose job it is ostensibly to be good Qt developer citizens, but whose actual job is to guide the next major version of Qt (which will break stuff) into breaking as little of my stuff as possible.
The second worst (but still bad) way to make a native cross platform UI is to give up, and make a not UI but close to UI cross platform abstraction layer, and then do the half dozen abstraction layer to native UI things separately. That still sucks more than the arena football league though.
No one's ever really done this, so it definitely sucks more than I think it does. But I walked into that suggestion knowing it sucks, so I don't feel bad. I dunno man. Everything about cross platform UI sucks.
> "Just copy whatever Apple does" seems like the worst possible solution for a cross platform widget naming convention out of many possible bad solutions.
The suggestion wasn't about copying whatever Apple does.
It's that SwiftUI has the most simple syntax (that I've seen.)
If you can make it nicer and more succinct than that, go for it!
But how is that the "worst possible solution?" What OS-specific bias do you see in that?
So maybe the specific constructs for specifying view modifiers and enums could be slightly different for each language, or the ()s might be []s, and maybe we could do away with the {}s.
It would just be a model for describing the UI, that a hypothetical engine backend might take and spit out OS-native widgets. For another OS, you'd plug in a different engine.
If Druid is going to build its own widget system from scratch anyway, what makes it more native than something like Electron? For me, the primary reason I'm interested in finding alternatives to Electron is to avoid shipping an entire UI framework + rendering engine with my code.
At least at first glance it seems to me like if I'm avoiding native OS toolkits, I might as well just target the browser anyway -- or is there something I'm missing?
Nativeness is a scale, for sure. Druid tries to be more native in certain ways, such as using platform drawing API's (Direct2D on Windows) when they're appropriate. I think the main reason to choose druid over browsers is simply performance. Also, druid binaries are pretty small, for example the calculator is 792k.
Of course, things have gotten a bit postmodern, even on macOS there is no single widget toolkit, but basically a series of choices of what technology to build on. I'm actually not sure that binding other languages to SwiftUI is going to work well at all, but in Objective-C it works fine, just isn't very smooth. On Windows, I've generally found COM to be quite pleasant, and noises coming from Microsoft suggest that story will become even better.