4 ms·

(Disclaimer: My knowledge of Rust very limited, but I have quite a bit of experience with getting Qt/KDE classes to work with other languages.) You are absolut

by sime2009 5y ago

(Disclaimer: My knowledge of Rust very limited, but I have quite a bit of experience with getting Qt/KDE classes to work with other languages.) You are absolutely right. The effort to be acceptable bindings for Qt would be a tiny fraction of the cost compared to building a whole new Rust native GUI library. Qt is huge set of libraries with an equally huge API. But there are a lot of shortcuts and smart ways of approaching the problem to get what you want out of Qt for minimum effort. Bindings like PyQt and even PySide go for the nuclear option of generating bindings for the whole Qt API and trying to match the C++ API in style too. This is an absolutely massive huge task. Also, getting people to contribute to an open source bindings project is hard. Getting people to contribute to a bindings generator is even harder. NodeGui https://github.com/nodegui/nodegui https://github.com/nodegui/nodegui, Qt bindings for Nodejs, on the other hand takes a very different approach which in one way is low-tech but I think is actually very smart. I'll summerise the differences: * It focuses on Qt Widgets first. This greatly reduces the amount of work to the parts that people actually need. (BTW, if you just want QML and Rust back-end then Jos van den Oever's work at https://invent.kde.org/sdk/rust-qt-binding-generator https://invent.kde.org/sdk/rust-qt-binding-generator has probably got you covered already.) * Mostly hand written, no generation techniques being used. This makes the bindings code repetitive yes, but also easy to understand, easy to debug, and easy to extend. That greatly lowers the barrier for casual contributors. * Doesn't try to copy the C++ API 1:1. For example, to extend a widget in C++ you are expected to subclass it directly and override methods etc. NodeGui chooses a more composition approach where method you might override are instead exposed as events. Another example, the Qt API is encrusted with convenience methods and overloads. Most of these can be skipped or implemented purely on the JS side. * Intercepts most events via `QObject::event()` instead of trying to do this method by method (i.e. in QWidget's collection of event handling methods). Smart move. * Qt has a lot of tiny value classes which can be replaced in the API by JS native objects holding the same data.

j1elo 5y ago
I agree that a more selective approach might be better. The typical response when talking about bindings to Qt is that there are so many impediments to make a decent bridge between language X and the C++ land. But I think that while correct (I've suffered trying to do it myself), it never compares that effort with what would really take to do it from scratch and get to a comparable level of features or robustness. Not only because of the code itself, but because of the knowledge, the know-hows and know-whys of the field, all the tiny decisions that the original library made and you'll take ages to come up with and make too.

j1elo 5y ago

I agree that a more selective approach might be better. The typical response when talking about bindings to Qt is that there are so many impediments to make a decent bridge between language X and the C++ land. But I think that while correct (I've suffered trying to do it myself), it never compares that effort with what would really take to do it from scratch and get to a comparable level of features or robustness. Not only because of the code itself, but because of the knowledge, the know-hows and know-whys of the field, all the tiny decisions that the original library made and you'll take ages to come up with and make too.