orbtk VS kas

i was gonna bring up https://github.com/redox-os/orbtk only to discover it's no longer under active development.

OrbTk is sunsetting in favor of Iced, slint, and future renderer-agnostic toolkits: https://github.com/redox-os/orbtk

Orbtk

The GitLab repo was deleted. You will need to update the submodule path to https://github.com/redox-os/orbtk.

That said, I'm not totally convinced about SixtyFPS today. There are some other interesting options that are suitable GUI toolkits for Rust. Such as OrbTk and Iced. Each toolkit is approaching the GUI space in a different way, so it'll be interesting to see where we end up in a few more years. QML-esque SixtyFPS, ECS-based OrbTk, Elm-based Iced, and a few others out there.

What's written in this article isn't the development of a GTK fork, but some reasoning for exploring alternatives to GTK. There aren't very many suitable candidates in this space, but Rust GUI toolkits like Iced have potential. Personally, I would add that OrbTk is also a suitable candidate.

I use orbtk, it is pretty easy to use, has an active dev team, works on windows mac and linux, and cross compiling from linux to windows is also easy with it. It is still pretty beta, but depending on the project you need it could work. (https://github.com/redox-os/orbtk)

Orbtk is an option. The default is backend is orbraq, which uses OrbClient. OrbClient will use SDL on Linux, and on Redox it should be a "pure" rust experience.

OrbTK recompiling stuff has been fixed in the development branch as far as I can tell: https://github.com/redox-os/orbtk/pull/409

OrbTK

Qt classic/widgets? I'm developing Kas to offer vaguely similar features (e.g. data models, theme abstraction, custom widgets with complex event handling), though said event handling and data models are quite different. It's still got a long way to go (so API is not stable), but in case you are interested, I should be dropping a new release tomorrow.

KAS GUI

kas-wgpu looks hopeful, but there's very little information about it and I'm not even sure it works on Android.

Changelog

The next release will support dynamic linking which approx. halves the recompile time in my quick tests. This is based on Bevy which also recommends using LLD (see here); I didn't have much success with this yet however.

If you want a "native-like" toolkit like Qt but Rust-native, then Druid, KAS and Iced are the most advanced in my opinion (though all are incomplete).

Yes. It was actually a mistake (using a nightly compiler and not realising the lock-in). But in this case (with KAS still in "earlyish development" and the workaround being less concise), I decided to leave it.

This is a little library I've been using recently (original version here).

Hello, I am github.com/dhardy, maintainer of rand, former dev of OpenMalaria epidemiology simulator, author of KAS GUI and Rust enthusiast since 2013. I may be interested in positions within Europe.