5 ms·

I've worked as a GUI developer with Qt for years in the past, and I think that library/framework is an awesome technical feat. It would be a pity if Rust (or an

• nybble41 5y ago
  It's not just a matter of putting in enough man-hours to create decent bindings. Native-C++ libraries are hard to write good bindings for in the best of times, typically requiring C wrappers with limited functionality and/or significant runtime overhead. Creating workable and safe (but still non-idiomatic) bindings for a C++ library from a language like Rust with a very different object model (can't use C++ templates or define new C++ subclasses; functions called from Rust must not throw C++ exceptions) and a far stricter type system than either C or C++ (borrow checking, lifetimes, thread-safety enforced at the type level) can be next to impossible. Even if you succeed, the result will be restricted to the least common denominator supported by both C++ and Rust and will never feel like a native Rust library. This is not to say that Rust could not benefit from the significant effort which has gone into developing Qt, but a Rust port of Qt might be more workable than bindings to the C++ toolkit.
  • j1elo 5y ago
    > a Rust port of Qt might be more workable than bindings to the C++ toolkit. That's an interesting idea! it might be worth considering it, at least. I wasn't thinking of a full-blown bindings that cover 100% of the API which is an immense task and, as your sibling comments thinks, was a mistake. A more opinionated stance of what parts of the Qt features are deemed necessary seems more feasible in the short to medium term. I wasn't advocating for one specific way of doing it, but for the more general sentiment that reinventing the wheel and creating a new toolkit from scratch is definitely the most expensive of all the options, in terms of human effort, time dedicated, and progress achieved. We'd basically be decades later than other OSS options, why not build upon their shoulders instead?
• 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.