It is great to see how many people want to bring Qt support to Rust and are trying to do so, and I hope that these folks succeed, but it’s wearisome to me how each person/group creates a new project instead of working with others who are already in this problem space. Of the half-dozen or so[0] existing attempts so far to create Qt bindings to Rust, none of them have actually succeeded, either because they tried to start from scratch again and then abandoned the attempt midway, or because they are limited to QML. Ritual[1] is the only crate I’ve seen that attempts to actually expose the whole Qt API, but it’s pretty awful to use, incomplete, and dead.
Rust doesn’t need more Qt crates. It needs one Qt crate that is complete and works well. (Or, ideally, a native Rust cross-platform GUI crate that works as well as Qt, but that’s an even longer and harder task.)
The thing is that Qt is a C++ toolkit written in C++ and meant to be used from C++ with its C++ API.
Especially if we want to use QtWidgets, the API surface is huge.
There are a bunch of bindings with different language, but even the ones that are officially supported like PySide will still be second class citizen and awkward to use.
Automated binding generation will never give you idiomatic API in whatever language. And if you want an idiomatic library that wraps Qt, it's going to take a huge amount of work.
Which is why I think restricting to QML makes sense because that's a much smaller API surface. That was the ambition behind my previous crate that exposes QML to rust: https://github.com/woboq/qmetaobject-rs/
But now I've moved on to another GUI project: Slint https://github.com/slint-ui/slint
It is implemented in Rust, but from the start aim to expose its API to several programming languages so bindings can be made idiomatic in almost every programming languages.
It's totally reasonable to lament duplicated effort, but it's worth pointing out that this particular attempt is from a company[0] whose business is Qt consulting - so it's easy to imagine that they might succeed (due to expertise, size, and motivation) where others have not.
The post also explains why they started from scratch vs. existing approaches - I'm not qualified to evaluate the claims, but I think they deserve some credit for explicitly talking through their reasons.
Quite frankly, I'd love to have some idiomatic C++14/17/20 bindings for Qt.
The official Qt for Python binding fits in very well with the language and style I think, but when using it in C++, I have to mix wildly different styles and me no likely.
Idiomatic C++98 and idiomatic C++17 might as well be two different languages. Using Qt, you'll feel forced to unlearn much of the recent good stuff and code like it's 98-ish. The fact that Qt comes with many of it's own standard types (QString!) without automatic conversion (unlike Qt for Python) makes it verbose and integrates badly with STL types. Then there are still some macros you need to use (e.g. for Connections).
In Python they did an excellent job with all of that.
What more integration do you need ? Qt types are able to use move semantics, are compatible with standard algorithms, support function objects and thus lambdas for callbacks, standard atomics, there's QStringView to match std::string_view use cases... What else ? Hell, it's trivial to make Qt work with c++20 coroutines ; Qt itself requires C++17 compilers since Qt 6
Integration is for instance not having to use QString(View) is the first place, like one doesnt with many of the bindings, including Qts own Python binding.
If you can show me a codebase that you think is modern C++ and uses Qt, it would be much appreaciated. I keep running into walls and havng to go back to coding like it's 98 basically, but hey, love to be shown it's me.
> Integration is for instance not having to use QString(View) is the first place, like one doesnt with many of the bindings, including Qts own Python binding.
that's because Python has unicode strings. C++ doesn't have a single, canonical unicode string type.
QString and QStringView are fundamentally different data types than std::string and std::string_view which aren't unicode ; the std::string and std::string_view Qt equivalents are QByteArray and QByteArrayView.
Interesting. Based on my understanding, it seems that they solve the biggest hurdle in cleanly implementing Qt bindings - the lack of inheritance - by using macros.
On a small project of mine, macros were also my choice for working around lack of inheritance; I wonder how this scale on large(r) projects, including this one.
RQBG is not changing a lot any more because for me it works fine and some people are using it. There's currently one patch in the works, but other than that it's stable. Initially, I blogged quite a bit and put effort into good demo applications. But no feature requests or patches were forthcoming. Which is fine by me. The project was meant to be simple and stay simple.
This project takes the same approach. It is aimed to put Rust at the core (business logic) of the application and code the UI in C++ or QML. This way you sidestep the enormous work of writing bindings for the Qt libraries.
KDAB hires some of the best Qt coders, so this effort by them might get more traction. Using macros and annotations like Oliviers project is nice. When RQBG started procedural macros were not attractive yet.
This new project is on Microsoft GitHub which means I won't be contributing. I prefer to work on projects that are self-hosted by communities like KDE, GNOME, Debian instead of being locked on a closed platform of a competitor.
This sounds awesome! Rust seems like it should be a good fit for native applications (Nice language+tools, and fast), but its lack of robust GUI tools limits this. This should help, if it works well.
An idiomatic binding to wxWidgets would be a great alternative to Electron-like solutions for multi-platform GUI. AIUI, there's already a wxC project (i.e. a pure C foreign interface for wx, needed to support other bindings) and a Rust binding could be built on that.
Is wxC maintained? I didn't think it was. I always thought a more interesting approach would be like the one wxPython uses. They effectively walk the object tree generated by Doxygen docs and do code generation from it. Not sure how viable it would be to do this with Cxx directly or if it would be better to generate a C based API from it AND a Rust wrapper. The latter has the advantage that multiple languages could write bindings against this C based API (like wxC), but since generated, less maintenance.
I don't think wxC is supported anymore. Its SourceForge (lol) page lists 2013-04-15 as the last time it was updated. I believe with all the nice tooling that's popped up in the C++ space over the last decade (e.g. libclang, cxx) could allow bindings to be created more easily/sustainably. Someone has to do it though :)
AFAIK, the only complete desktop GUI option for Rust that is viable for large, professional apps is gtk-rs. There are many promising up and coming GUIs for hobby projects, but none I've seen are robust enough (yet) to support all needed widgets of a pro app.
Accessibility support is the big killer for many of them, though even GTK has issues with that on Mac OS, so Qt would be a big win.
Or I guess you could put a Rust wasm app into electron also and have accessibility support that way. Has to be one that uses a real DOM and not just renders to a canvas or WebGL though.
Ahh...very cool, thx. Didn't realize it was that capable and was not aware of this "demo". I will check it out as I need to write a GUI soon (and would prefer to use Rust).
There are plenty of GUI solutions that are robust enough for an embedded GUI or some WebAssembly stuff. For native (desktop) applications the rust ecosystem still has a long way to go.
This looks like what we usually call a "heavyweight mapping", distinguished from the usually preferred "lightweight mapping".
There are sound reasons to prefer the latter. When it is lightweight enough, the mapping is intuitive and obvious, so the original documentation mostly suffices, modulo some release notes. If something doesn't work right, is is very likely your code, not the mapping, at fault. Anything omitted from the mapping is easy to add, compatibly.
The promise of a heavyweight mapping is always that you won't need to understand the thing mapped, that the mapping itself will (1) be fully documented, and (2) work. Neither is ever wholly true. As a result, you need to understand both libraries, and also the (lightweight) mapping between them, and work around all the bugs and infelicities in all three -- mostly without help, because nobody else understands all that any better than you do. When something doesn't work, you have to determine if it is your code, the mapping library, or the thing mapped that is at fault.
Lightweight mappings are always ugly. You end up with your own, custom, heavier mapping, but just to the parts you are actually using, and that you actually understand. It is tempting to fill that out and publish it, which is the actual origin of all the mappings you find published. Resist.
Sorry if off-topic but I've seen many attempts at Qt bindings from Go and Rust. It seems all GUI libraries are more than 15 years old - except flutter, which is currently alpha quality on desktop.
As someone who has never implemented a native GUI library, what makes them so difficult to implement that we see so almost no language-native ones? Is it a matter of it not being monetizable, or something else?
The hardest is to make multiline text input and rich text support. None of the smaller, home-brown GUIs gets this right. You basically have to write a complete editor that supports all languages, including Japanese, Chinese, Arabic, etc. Even native operating system text input widgets have been plagued with problems. Generally, there are tons of edge cases and special input considerations to consider in a GUI, e.g. DPI scaling, accessibility, right-to-left languages and unusual unicode glyph handling (composed glyphs), scrolling behavior & mouse handling, platform-dependent layout issues (HI guidelines), escape characters in file paths and unusual file systems, and so on and so forth.
It's quite possible to make a good GUI, just lots of mundane small issues to deal with, and it's overall a massive undertaking. It requires at least an extremely good knowledge of how different languages deal with text and input it.
harfbuzz is for text rendering, not editing. Of course, the former is a prerequisite for the latter, but text editing has plenty of its own complexity.
Qt5's qtbase module is over 2 million LOC, and doesn't even cover QML, QtQuick, etc.
Just having proper abstractions over each platform[1]'s:
- windowing
- KB/mouse/tablet/touch input
- raster painting
- 3D APIs (Vk, D3D, GL, Metal...)
- text layout and rendering
- support for accessibility APIs
+ things such as generic data models for tables and trees, etc... is already an immense amount of work, and you haven't even started drawing a single button yet.
You do not need to replicate all features of Qt to make a GUI toolkit, especially since Qt tends to have a ton of stuff outside GUIs and actually has two "widgets" approaches (classic widgets and QML). For example the 3D API stuff are pointless beyond context creation, unless you use only that 3D API (instead of underlying window system functionality) to put stuff on screen.
Qt also recreates a ton of features found in C++ and if we're considering a new language, chances are the language itself has features that make Qt's unnecessary.
Which features are you talking about ? Even in c++23 there isn't yet a way to replicate moc, rcc, uic with the same ergonomy for the end user and the same efficiency.
I mean things like containers though in the context of a new language chances are the language itself may provide functionality that makes moc unnecessary.
Also you certainly do not need something like moc to make a GUI library, which comes back to what i originally wrote in that you do not need to replicate Qt to have a GUI library.
There sure is some overlap with what Qt offers that most language offers (Containers, Networking, Database, threading, ...).
But purely in the context of making a UI library, there is still a huge amount of things that Qt offers that needs to be replicated.
The post i replied to was about how big Qt is, which includes containers, etc. That the specific examples given did not contain "containers" isn't relevant since they are part of the "2 million LOC" mentioned.
Yes, you need to implement similar functionality, like abstracting the window system, input handling, text, etc but you do not need to replicate what Qt does to have a GUI toolkit.
Qt is very complex and Qt is (among others) a GUI library but Qt being complex doesn't mean that GUI libraries have to be complex.
...but, as others have noted, even if you want to only support the "core" features that most people would take for granted for a GUI (cross-platform, all the "usual" widgets including complicated ones such as RichEdit, ListView, TreeView, text with Unicode support and subpixel rendering etc. etc.) it's already a massive undertaking.
That is another issue, yes, it is not trivial (though it isn't like making a browser or even a game engine - especially since game engines nowadays tend to have their own GUI toolkits :-P) but my point was that you do not need to replicate what Qt does to have a useful and usable library.
Correct. You don't have to replicate anywhere near what Qt has to make a useful toolkit.
However, here is your experience with almost every other toolkit: Download it, compile it, build a couple test screens with it, maybe even build a couple of your production screens with it, then the inevitable disaster: You have some requirement, and you need a calendar that can highlight certain dates, or that gives you mouseevents on each individual date, or allows Jewish as well as Gregorian calendars, or that allows you to add things between the month name and the month days other than what the widget already puts there, or that... etc., for any of dozens of specialized requirements. And then you bounce off the toolkit and tell people in online discussions that you really enjoyed working with it, it was nice that it was so simple, and it has a lot of promise and you hope the developers keep working on it, but it wasn't suitable for your needs and Qt had exactly the widget you needed or at least the widget you needed had the plugin points you needed to do your job.
(In the meantime, the project stalls and dies because nobody else is using it either, but all for different reasons.)
And you hadn't even gotten a tenth of your dialogs started.
Another common one is, as people say, trying to add a rich text dialog and getting hit hard by bugs, counterintuitive behaviors, internationalization issues, etc.
Nobody uses all of what Qt offers. I can't even imagine what it would look like for a program to use literally everything it has. Even a full office suite would be pressed to do that. But everybody uses lots of different things. Put 10 Qt GUI users together and they'll use very different subsets beyond the bare basics like layouts and simple buttons.
Simply to write a binding to a GUI toolkit, ignoring all the other aspects of Qt, is itself a major project. There's been more than one Python project for it, and it is a project, generally more than one person could hope to do. To write a full toolkit that won't give people the experience above is enormous.
And that is why it is important to select your language carefully if you're writing a GUI-heavy project. You can't just pick up your favorite language and casually expect every widget you need to be available. Even if you nominally have "a binding to Qt" in your language, in my experience it's important to still double check that the binding to the widget(s) you need actually work, because anything beyond those bare basic layout, buttons, and bindings to simple widgets everybody uses is still quite possibly broken, or incompletely bound so it can't actually be used (which means nobody can have ever even tried this widget), or straight-up missing, or it's present but there's no way to correctly subclass something then make the bound widget use your subclass (in the foreign language) correctly, or something.
Nor can you just bide your time and hope a toolkit appears. They're enormous projects, even just to get one to the point that most developers don't generally hit a vital bit of missing functionality, let alone to get one full of all the features someone could reasonably want.
Sorry but my experience with Qt has been neutral to negative. I can go and write a textwall about all the issues Qt has and personal experiences i had with it myself, but they're not really relevant here. Your message is basically "people stick with Qt because people stick with Qt so that is the safe bet" (aka "nobody was fired for buying IBM"). Which sure, it is true and a big reason why you do not see other toolkits much, but this doesn't really have to do with what i wrote.
Grandparent's point is that, in something with less functionality, you will hit missing feature X quickly, and it won't be the same missing feature as any ten random other developers. It is just your interpretation that it is, somehow, primarily about inertia or image. Joel on Software has an essay about (missing) features: https://www.joelonsoftware.com/2001/03/23/strategy-letter-iv...
I get that point and i disagree because it makes two assumptions:
1. That you need to replicate Qt to have the same or equivalent features for a GUI toolkit (remember that what i made explicitly that Qt is more than just a GUI toolkit) or you will not have the same features at all
2. That you will "hit" said missing feature
None of these have to do anything with making a GUI library though. #1 is especially questionable since even if you need the non-GUI functionality Qt provides, it might be something the language already has (remember that this is about other languages aside from C and C++) and/or you may even find a separate library that provides such functionality.
And yes, inertia and image does affect A LOT. People do choose projects only because of the perceived safety of those projects from being used by other people. This is why regardless of features, many people stick or flock to languages/libraries/frameworks/etc for their communities and "community" or "ecosystem" is a common concern about something new. This is something you can see often in Hacker News posts too.
It is an enormous effort (read investment) to get to a point of detail, where such a library becomes usable to a wide audience.
Consider a simple text input: In some languages (e.g. 'syllable based' korean Hangul) you have to compose multiple keystrokes to get to a complex letter. While you type, the last and as well as the second-to-last complex-characters might still 'trade' consonants and vowels among each other.
Now layer in more Dimensions, such as validating that input or line-wrapping, elision and many more.
To my mind, only few libraries got to this level of detail without breaking apart on complexity. It requires high maintainer stamina or massive investments.
Most of your input example is nowadays typically handled by code outside the GUI toolkits themselves (such as the IME, the text shaping and the font stack), although the general "the GUI devil is in the details" thrust is right.
There is a lot of stuff there. When I think of Qt, and omitting things like QString and QIODevice / QNetwork: Text rendering, list / grid / tree views, painting primitives and not-so-primitives (e.g. dashed lines), input including multitouch, custom styling, accessibility, many miscellaneous widgets, timers and events, integration with native environment, printing - and a ton of customization points for everything.
Beyond the "this is too hard" responses (which from personal experience working on GUIs and toolkits for decades i think are overblown), it is also that a GUI toolkit -or any other library really- written in a niche language will only be usable for that niche language's audience but a GUI toolkit -or any other library- written in a language that can be used by other languages with almost zero friction, is way more likely to be used.
And people tend to use what they see other people using, thus repeating the cycle.
So you see these 15 year old libraries being used because other people are using these 15 year old libraries because they are written in languages that can be (relatively) easily be wrapped (both C and C++ wrapping can be done automatically and there are many tools for that - largely because this is something a ton of people want to do, so again, it feeds back to the cycle of things being popular because they are popular).
But there are lots of new toolkits being made, you can even find a submission for a new one in Hacker News almost every month (though the responses are pretty much the same in all of them :-P).
Also note that Qt, while having a legacy of its prior versions, has seen significant investments keep it up to date. You aren't using an "old" library, you are using a modern library in its latest incarnation.
Assuming you are talking about Qt/wxWidgets, and I don't think they are easy to create bindings for due to being written in C++. I think they have been used because they represent the largest, most complete crossplatform codebases representing the traditional desktop GUI using either native widgets, or in Qt's case "simulated" native looking widgets.
In contrast, GTK is written in C AFAIK, and anytime a new language springs up the very first thing you generally see is a GTK wrapper. I have always suspected this is because C is far easier to wrap since most languages have a well defined C FFI, but typically lack a C++ one (due to lack of std ABI) thus Qt/wxWidgets bindings typically lag GTK.
C is also a relatively simple procedural language which constrains the APIs that e.g. GTK can offer. This makes working with GTK in its native platform uglier than Qt, but does mean alternative bindings can build their own more ergonomic abstractions on top of it.
Qt on the other hand is very much a C++ OOP style, so if there's an impedance mismatch representing that in your language, as is the case for Rust, C or Go, then it gets much harder to do. The C++ bindings do present difficulty of course, but you can see from e.g. PyQT that if the pattern works in your language it's one that can be overcome.
And there are other choices Qt makes that are unfriendly for, say, Rust too, QString is defined in terms of UTF-16 code units, which was probably a pragmatic choice when Qt was younger, but inconvenient today since of course Rust can't necessarily be confident this is actually Unicode (I tried but was unsuccessful in figuring out what CXX-Qt does about that) and on non-Windows systems Rust doesn't have a built-in representation for this "a bunch of UTF-16 code units" pseudo string, yet on Windows you probably do want that structure because it is what other Windows stuff expects such as the File APIs...
This a good point, and I agree that C++ made sense at the time as it is much richer for creating a GUI. I've never tried to use GTK C GObject interface, but I've seen some snippets and it looked nasty to me. However, in hindsight, it at least makes it fairly easy to create bindings for and I suspect many (most?) don't use the GTK C API but some other language bindings, so it turned out to make a lot of sense I think.
There are tools to create bindings for C and C++, like SWIG you can see some examples in [0], e.g. the wxWidgets bindings for Python. AFAIK for Gtk bindings can be generated using gobject introspection handling most (if not all) of the mundane bits.
I'm aware and have used SWIG. It is amazing, but a) it doesn't support all languages b) it still takes a lot of work to create C++ bindings. This is primarily due to the complexity of C++ APIs vs. relative simplicity of a C-based API as another poster commented, not any shortcoming of SWIG.
So yes, there are tools, my point is it is still much easier to wrap a C based API because you can often just use your language FFI, not an external toolset.
Sure, i do not disagree that wrapping C++ is harder than C, but my point was that the language is widespread and popular enough to actually have tools that assist such wrappings, unlike other languages, so even if all else were equal you are more likely to see a C or C++ library be wrapped than -say- a Free Pascal library (which can create DLL/so/etc that are 100% compatible with C and thus wrappable).
They can be among the harder parts of a toolkit (though it also depends on the toolkit's scope - can't really compare something like Qt that has a very large scope going even outside GUIs with something like imgui, which only provides the most barebones GUI functionality) yes, but i think the "hardness" exists not in how hard they are to have that functionality but in most people not even thinking about these things.
Legacy code. I've been doing QT for 10 years, I only heard of rust about 3 years ago, but the hype (particularly memory safety) has got me very interested. If I can take some existing C++ that is due for major surgery for other reasons and write it in rust I'm interested.
We know from experience that rewriting our entire system from scratch will take 5 years and cost $150million: I won't even attempt to convince management of that. Our current C++ should be good for 25 years as just C++. if we maintain it well (the major surgery mentioned above) it can last indefinitely. However replacing the current QT GUI is not on the table, it already has our themes. Maybe someday in the future it will be on the table if there is better one and it can work well (look at feel) with out current QT GUI, but for today we don't complain about QT.
They're just really enormous libraries with a ton of tiny details you have to get right. Same reason there are so few good FOSS CAD programs or word processors. Tons of work.
There's a lot of requirements creep, the bar is high, since the estabilished stacks have had decades to build up their feature sets. Complexity multipliers include accessibility, cross-platform, gpu acceleration, complexities of text in the modern world (unicode, fancy rendering like subpixel aa, fonts, bidi...), programming language bindings, memory/lifetime management in presence of different mutually incompatible PL memory management models, native code hostile mobile platforms, etc. Leave any of those out and you start halving your potential users for each feature.
(For more specialised, niche gui toolkits the answer is that they're out there, but you've never heard of them because they don't enjoy the network effects that a wider user base gets the big toolkits)
A high quality desktop GUI library is close to a game engine in terms of difficulty. You have to support a vast array of languages, accessibility, input paradigms, flexible layout, different screen resolutions and DPIs, styling, and so on. It's a massive undertaking.
Considering that some game engines tend to have their own GUI toolkits (e.g. UE4's Slate for example), you can say that it is more difficult to make a game engine than a GUI toolkit :-P.
I'd say making a comprehensive 2D GUI toolkit is actually more complex and difficult than making a 3D game engine - even one that includes a rudimentary 2D GUI toolkit. There's an enormous long tail to 2D.
My current work is exactly at the place where those tech universes overlap and integrate.
Is the long tail you're talking about more in 2D rendering itself, or in accommodating the great diversity of the humans using the UI, e.g. accessibility and internationalization?
Rendering does have a lot of interesting 2D-specific problems too that 3D engines don't optimize for (Raph Levien's blog has great stuff on this), but what the 3D engines lack is often more related to UI layout, input (e.g. sophisticated focus handling), advanced text (editing, layout, shaping).
Unity's probably been investing the most into a more complete 2D toolkit (which is their third or fourth generation of 2D UI toolkit bundled with the engine) lately. Among the FOSS game engine projects Bevy has made strong 2D suitable for UI an explicit goal. But that one true converged contender is still not even on the horizon yet, IMHO.
Game engine toolkits usually don't have to support accessibility, right-to-left languages, full Unicode, and many other things that mature application UIs need.
I'm not sure about RTL but AFAIK UE4's Slate does have unicode support and also seems to have accessibility support. If the tools built on Slate use that though, i don't know, but that is the same as any toolkit.
Rust has a number of burgeoning GUI libraries. Some of them are further developed than others. I think the difficulty is just the complexity of the work. It takes a lot of effort to make a complete, functional library, and many of these are largely the work of one to a few people (probably in their spare time)!
Small tip: put a working example when you advertise such an API with a screenshot as a bonus. As a developer I want to see if the bindings feel natural and maybe try it right away. Here both the article and the GitHub readme lack this.
It' says "a working example" - which we referenced. With "a screenshot as a bonus". And a screenshot is pretty pointless for a binding library, since it doesn't impact what the GUI looks like, so it's not surprising a simple example to show the code doesn't have one.
EDIT: i.e. after looking at the QML, from quick glance it'll render two lines of text and two buttons in QML default styling. What do you gain from that?
Although I agree that screenshots will attract some people, it's Qt. The look and feel won't be any different from any other Qt application (or better, it will be completely dependent on theming, so the pictures won't even reflect what you get.)
so say that, instead of playing this fake "oh I don't know and have nothing to do with it, can anyone help" game. Know your audience. It's HN, mentioning your alternative is accepted here as long as you're fair and honest about it, especially since this isn't even a Show HN.
Great to see official support, albeit I never understood the move to QML and the existing Qt bindings are enough.
I don't really need anything more than QWidgets.
Interesting to see the dual MIT-Apache license approach. I'm less familiar with Apache, but what does it offer that MIT doesn't? Is it just to allow downstream projects and forks to choose which of the two licenses they prefer? If so then the GPL is curiously missing.
Apache license has some language around patent grants that some people want and other people don't like (e.g. apache isn't compatible with GPLv2, some of the BSDs reject it, ... and some people just think its too complicated). Thus offering both makes both sides happy is my guess.
I've had fantastic luck using pyqt5 in the past, but it kind of bothers me that both pyqt and pyside both exist. They look nearly identical, and I never know if I'm using something which will eventually be dead.
To some extent the intent of the author matters, and in their "Just buy a license" pitch[1], the Qt company implicitly threatens lawsuits for GPL violations _if_ you use the open source version and fail to provide an adequate means to switch out the linked binaries. So the people who could enforce a copyright claim are drawing that distinction, which means it does matter here. In addition, they mix licenses between GPL and LGPL, so failing to take proper care means you could be relying on a GPL module and think you're ok by complying with the LGPL.
You can meet a major LGPL requirement by dynamically linking your dependencies or by providing object files that the user can statically relink. Neither is circumventing the LGPL, however.
I take your point the Qt company wants (L)GPL licensing to sound scary, so they can sell licenses.
Cargo links all the rust code together in a static binary, but the C/C++ libraries can be linked dynamically, and in the case of something like Qt, most certainly are.
Since most important part of Qt are LGPL, you can use this crate and other Qt binding crates to develop proprietary applications.
(Only if you wish to use one of the few parts that are "only" GPL, then you need to release the final product and all its parts under the GPL, or acquire a Qt license)
Rust doesn’t need more Qt crates. It needs one Qt crate that is complete and works well. (Or, ideally, a native Rust cross-platform GUI crate that works as well as Qt, but that’s an even longer and harder task.)
[0] https://lib.rs/keywords/qt
[1] https://github.com/rust-qt/ritual