Rust-Written GUI Toolkit Slint 1.3 Brings Initial Android Port, Native Styles On Windows

[ClosedSource]

Binding Qt's entire API surface is difficult since it's a giant C++ API that relies on subclassing in various places and a history of using their own language extensions via moc, so there are currently no non-unsafe Rust bindings for it.

I was picturing the opposite. Write in C++ and use your Rust code within the C++ project. Would that be possible?

[darkonix]

I was picturing the opposite. Write in C++ and use your Rust code within the C++ project. Would that be possible?

Slint page says it supports Rust, C++ and JavaScript clients.

[ssokolow]

I was picturing the opposite. Write in C++ and use your Rust code within the C++ project. Would that be possible?

Take a look at https://lib.rs/crates/cbindgen or https://lib.rs/crates/flapigen for generating C++ header files from Rust code.

As for using Rust in C++ Qt projects specifically, check out the options listed at https://github.com/KDAB/cxx-qt#compa...st-qt-bindings

[tobias]

I was picturing the opposite. Write in C++ and use your Rust code within the C++ project. Would that be possible?

Both directions (use rust in a C++ project and use C++ in a rust project).

Converting between languages is pretty tricky though. There is tooling available to help, but C++ maps poorly to rust and vice versa, so there is some level of coding involved. Those interfaces are unsafe in most cases and having a safe wrappers around that requires more work and a deep level of understanding of the APIs involved.

So it works best to replace a module of the code base that integrates to the rest of the system using a small interface.

Qt has a very broad interface with lots of exposed classes and helpers and idioms. It provides a huge interface with all kinds of helper classes like QString, etc. you need to talk to the rest of Qt. This is pretty much the worst case to write a rust wrapper for. Qt is also actively developed. You have to so follow along all those developments on the rust side to keep your work relevant.

Including a C or C++ dependency into a rust codebase does complicate the build. Suddenly you need an extra compiler, need to detect that dependency on the system, etc. Rust devs are so spoiled with cargo...

[Quackdoc]

Including a C or C++ dependency into a rust codebase does complicate the build. Suddenly you need an extra compiler, need to detect that dependency on the system, etc. Rust devs are so spoiled with cargo...

indeed we are, it also makes crosscompiling way to easy . mixing C/++ into that is quite painful

[moltonel]

If you read carefully, very, very few things have been rewritten to Rust. Most of the time it's just new projects that chose Rust over C. Even coreutils that says about itself that it's a rewrite, is just a new project trying to duplicate GNU coreutils. Meanwhile, GNU coreutils is still alive and well.

I'm not sure I follow how you define an "actual rewrite". You seem to imply that it has to officially replace the previous implementation and/or to be (re)written by the same team as the original ? IMHO this leads to some strange conclusions, like Arti being more of a rewrite than uutils-coreutils, despite the later being much closer in spirit to its original. Or the fact that you could only label something a rewrite after it has achieved success and replaced its original.

IMHO what matters more is how close in behavior or purpose you are to the original, and uutils, sudo-rs and librsvg are clearly rewrites. Arti, Ripgrep and Servo are semi-rewrites, considering how much they changed (improved) along the way.

Many times when developers choose to implement something that already exists, they do it to test their own Rust prowess. Or to test whether Rust is feasible for a particular type of apps.

You seem to be only considering toy projects. You forgot the biggest motivator of any successful project: to build something better than the current offering. If a rewrite isn't (already or expected to become) in some way better than the original, you won't hear about it.

My own emlop is a rewrite of genlop, and the main motivation by far was to make a better tool. I considered contributing to original genlop directly, but Perl was a turn-off (despite having used it professionally). First comes the decision for a rewrite, then the choice of Rust (other languages could have worked too, but Rust fits the usecase well, and I wanted to improve my Rust because we had started using it at work).

[fluke]

Sint is... (you guessed it!)... fat *bindings* against the Qt library.

Amazingly it also drags in more dependencies (NPM-style) than Qt itself utilizes.

Bullshit. I use slint for both work and hobby. QT is not a requirement for it, slint has multiple backends.

[oleid]

Sint is... (you guessed it!)... fat *bindings* against the Qt library.

Yes and no. Qt is one of the render backends it supports.