Sure, cross-platform UI that's on the metal is a more accurate description.

Do you have any plans of open-sourcing the UI framework?

We do have plans. Stay tuned!

Also with your custom UI framework, you will need to re-implement a text editor from scratch which is a pretty daunting task by the way [0]. Do you also have plans to open source the text editing / make text editing a part of the framework? Text editing (right there with accessibility) is the core reason why one would not go with a pure immediate mode GUI for any app. I guess you are baking immediate mode with some extras?

[0] https://www.construct.net/en/blogs/ashleys-blog-2/simple-sof...

Rust on Mac with an open source UI - wow! If nothing else, you guys are ambitious as heck. Can't wait to see more. Also, loved the youtube video you linked to earlier in the comments - great to see an actual working demo instead of just an announcement.

That's awesome! How far off in the future is that? Is it more like a 1 year or a few years?

This sounds awesome! I hope you post it here!

Did you consider using Flutter? If yes, what made you choose against it?

It's been a few years since I used Flutter, but doesn't it still require you to use the related language Dart? I liked the idea of it, and I thought the tight integration between Flutter and Dart allowed them to do some cool things. But I wasn't a huge fan of the language itself. And I think it's a lot to ask prospective extension-writers to learn a new language.

If you know Java or JavaScript, Dart is extremely easy to pick up.

Sure, but that doesn't help if your project is in Rust.

Rust actually has a library with very good flutter integration, it does require using dart for the actual flutter part though, but it works well together.

Are you talking about nativeshell[1] or something else? nativeshell looks to be in early stages of development still.

1 - https://nativeshell.dev

Sure, there's a whole class of languages that are enough like one another that if you know one you have an advantage picking the other one up.

On the other hand, it looks like Rust is only moderately more popular than Dart: https://www.tiobe.com/tiobe-index/

But I can see why they'd steer away from a language controlled by one company, especially one notorious for killing off projects.

We just wanted to be pure Rust and have complete control.

"Native UI" can be interpreted to mean "UI written in native (i.e compiled to machine) code" or "UI written using the OS's native widgets". You are presuming that the only correct definition is the latter, but it's pretty clear from context that they mean the former.

Yes, you can argue for another plausible interpretation of those two words, but in actual usage "Native UI" has always meant the platform's native UI framework.

A lot of people started to refer to Qt as native around Electron's time. The only place where Qt is native as such in on a KDE Plasma/LxQt desktop.

You're correct, although Qt attempts to do fake native widgets on Win / Mac, and given how relatively lightweight it is compared to Electron, it's understandable how it became a obviously point of contrast with the latter, which doesn't even pretend to be native. Given a choice between the two I will obviously take fake native widgets over nothing.

I, on the other hand, will take whichever widgets have the better accessibility implementation. Currently Electron beats Qt on this.

> but it's pretty clear from context that they mean the former

It absolutely was not clear, which is why I checked the website and then pointed out the lack of clarity.

At first my thought was "Wow, nice, another UI toolkit that uses native widgets, that's good!" But, alas, it was not to be.

I feel like people are talking about different things when they say "native", to me it's more about being compiled to native binary, or being performant, than "native UI".

I've never been impressed with native UIs in any platform, web or mobile. The only context where I appreciate them is accessibility.