Sorry, couldn't answer before, HN was doing its weird "you post too often" dance.
I guess I misunderstood the intent behind the project. I thought it's like a full alternative to GTK / Qt but in Rust which would be really nice to have, but I get that it would be a much bigger project than something built on top of them.
Ah, yes. There is cross-platform infrastructure we could use, which is what Iced does. We have chosen to do things a bit differently. In general, we use platform capabilities where they're available, for a much lighter weight build and less impedance mismatch with native look and feel. It's a tradeoff, and one of the downsides is that the Linux port needs a bit of extra attention.
Ultimately, I believe our approach will yield higher quality results, but there's a lot to learn from Iced as well.
I remember you wrote before that "there is no such thing as native GUI." Is that more of a high level situation, with text rendering and other lower level things still best handled by "going native"? What other things count as low level like this?
Yes. What I meant by that was more a reference that platforms increasingly support diverse ecosystems of UI toolkits, especially at the high level. Even on mac there's a choice between SwiftUI and AppKit (technically Catalyst too, but that doesn't seem to be a hit), while on Windows there is even greater diversity. So basically it's a way of saying "just use the native toolkit" doesn't actually solve as many problems as one might think.
At the lower level, for some things you really have to integrate deeply with the platform, and for others (text layout is one), there are advantages, including faster builds and smaller binaries. (Ultimately I'd like to have a highly GPU accelerated 2D graphics library that does everything, including text, but that's some ways off and doesn't block current work)
