11 ms·

CXX-Qt: Safe Rust bindings for Qt

157 points by jcelerier 5y ago

pizza234 5y ago
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.
- gefhfffh 5y ago
  The Rust Windows API provides a cast method to jump through the inheritance hierarchy. Previously, additionally, all base class methods were generated for derived classes (structs). This was removed due to high compile times https://github.com/microsoft/windows-rs https://github.com/microsoft/windows-rs
lordofgibbons 5y ago
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?
- ahartmetz 5y ago
  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.
- wuschelhase 5y ago
  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.
  - sho_hn 5y ago
    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.
- deleted 5y ago
  [deleted]
- jcelerier 5y ago
  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. * https://github.com/qt/qtbase/tree/dev/src/plugins/platforms https://github.com/qt/qtbase/tree/dev/src/plugins/platforms
  - badsectoracula 5y ago
    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.
    - jcelerier 5y ago
      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.
      - badsectoracula 5y ago
        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.
        ogoffart 5y ago
- IshKebab 5y ago
  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.
- jonathanstrange 5y ago
  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.
  - sharikous 5y ago
    Can't you just link HarfBuzz for that?
    - jcelerier 5y ago
      Harfbuzz partly comes from Qt's codebase IIRC
    - mwcampbell 5y ago
      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.
- beowulfey 5y ago
  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)! https://www.areweguiyet.com/ https://www.areweguiyet.com/ The secret, I suspect, is probably "money".
- badsectoracula 5y ago
  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).
  - mwcampbell 5y ago
    > from personal experience working on GUIs and toolkits for decades i think are overblown) Accessibility and internationalization are really hard though, right? I'm finally doing something about the accessibility issue: https://github.com/AccessKit/accesskit https://github.com/AccessKit/accesskit Still have a long way to go though.
    - badsectoracula 5y ago
      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.
  - nu11ptr 5y ago
    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.
- fulafel 5y ago
  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)
- api 5y ago
  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.
  - badsectoracula 5y ago
    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.
    - sho_hn 5y ago
      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.
      - mwcampbell 5y ago
        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?
        sho_hn 5y ago
        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.
- bluGill 5y ago
  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.
gbin 5y ago
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.
- Kelteseth 5y ago
  There is an example folder https://github.com/KDAB/cxx-qt/tree/main/examples https://github.com/KDAB/cxx-qt/tree/main/examples
  - detaro 5y ago
    And the start of the "book" also explains an example: https://kdab.github.io/cxx-qt/book/getting-started/2-our-first-cxx-qt-module.html https://kdab.github.io/cxx-qt/book/getting-started/2-our-fir... Fully agreed that should be more obvious though.
    - simlevesque 5y ago
      The first comment says specifically "screenshot" but the links you and the person you replied to mentionned both have no screenshot. We want screenshots. Images of the end product GUI.
      - detaro 5y ago
        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?
      - rat9988 5y ago
        Honestly no one needs screenshot. It's not showcasing a gui framework, but a binding to an existing one. I'd go as far to say that if you need screenshot for this, you may not be their primary audience.
dotancohen 5y ago
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.
- detaro 5y ago
  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.
- Rochus 5y ago
  Whatever license the binding has, open-source Qt is only available under LGPL or GPL.
- epage 5y ago
  Rust uses it and so has become a default license for Rust crates. See https://rust-lang.github.io/api-guidelines/necessities.html#c-permissive https://rust-lang.github.io/api-guidelines/necessities.html#...
  - dotancohen 5y ago
    I see, interesting. Thank you for bringing this to my attention.
oever 5y ago
Like the more mature <https://invent.kde.org/sdk/rust-qt-binding-generator https://invent.kde.org/sdk/rust-qt-binding-generator> this project avoids binding existing C++ code, but makes rust code available to C++/QML projects.
- sho_hn 5y ago
  Being familiar with your project I'm curious how this new one differentiates itself (other than being built on cxx).
  - oever 5y ago
    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. Here's a talk on the idea. <https://archive.fosdem.org/2018/schedule/event/rust_qt_binding_generator/ https://archive.fosdem.org/2018/schedule/event/rust_qt_bindi...> 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.
bagavi 5y ago
Do you plan to support rust integration with pyqt?
- fullstop 5y ago
  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.
  - nicoco 5y ago
    Fancy lasagna? Try qtpy! https://github.com/spyder-ide/qtpy https://github.com/spyder-ide/qtpy
    - foresto 5y ago
      That is the cutest project name I've seen in a while.
  - brnt 5y ago
    Pyside2, or Qt for Python, is now a Qt project, and can be expected to stick around for a long time.
ogoffart 5y ago
I wonder what problems from the list apply to another existing and more mature solution: https://github.com/woboq/qmetaobject-rs/ https://github.com/woboq/qmetaobject-rs/
- detaro 5y ago
  Given that the last commit is by someone with the same username as you, wouldn't you know better than random HN commenters?
  - ogoffart 5y ago
    Well, that's the thing. In my (biased) opinion, that crates doesn't have any of the problem mentioned. - The qmetaobject crate tries to be idiomatic rust and to be used without any C++ - As far as the user is concerned, there shouldn't be any call involving C++ - It does follow the Rust multi-threading guarantees - The License is the same as CXX-Qt - It does support plugins: https://github.com/woboq/qmetaobject-rs/tree/master/examples/qmlextensionplugins https://github.com/woboq/qmetaobject-rs/tree/master/examples... - It uses code generation via macro
    - detaro 5y ago
      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.
the__alchemist 5y ago
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.
- isomel 5y ago
  There are already plenty of GUI solutions for rust. All with a diverse level of polishing and convenience.
  - rapsey 5y ago
    A diverse level of incompleteness you mean. Nothing comparable to Qt exists.
    - isomel 5y ago
      Exactly. But there are already bindings to Qt in different states. Let's see if this one bring anything.
  - wongarsu 5y ago
    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.
    - the__alchemist 5y ago
      Yea - `embedded-graphics` is nice for embedded primatives and text.
  - nu11ptr 5y ago
    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.
jokethrowaway 5y ago
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.
hda111 5y ago
Can this dynamically link to Qt to circumvent the GPL?
- orra 5y ago
  Dynamic linking doesn't circumvent copyright law, so it doesn't circumvent copyleft.
  - Macha 5y ago
    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. [1]: https://www.qt.io/licensing/open-source-lgpl-obligations https://www.qt.io/licensing/open-source-lgpl-obligations
    - isomel 5y ago
      It's like asking "do you accept bitcoin to circumvent tax law" First of all, bitcoin does not circonvent tax law. (And linking does not circonvent GPL)
    - orra 5y ago
      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.
- oever 5y ago
  Qt is LGPL 3.0. Dynamically linking from close source is allowed.
mamcx 5y ago
csnover 5y ago
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.) [0] https://lib.rs/keywords/qt https://lib.rs/keywords/qt [1] https://github.com/rust-qt/ritual https://github.com/rust-qt/ritual
- mockery 5y ago
  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. [0] https://www.kdab.com/ https://www.kdab.com/
- ogoffart 5y ago
  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/ https://github.com/woboq/qmetaobject-rs/ But now I've moved on to another GUI project: Slint https://github.com/slint-ui/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.
ncmncm 5y ago
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.

157 points by jcelerier 5y ago

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.

gefhfffh 5y ago
The Rust Windows API provides a cast method to jump through the inheritance hierarchy. Previously, additionally, all base class methods were generated for derived classes (structs). This was removed due to high compile times https://github.com/microsoft/windows-rs https://github.com/microsoft/windows-rs

lordofgibbons 5y ago

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?

ahartmetz 5y ago
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.
wuschelhase 5y ago
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.
- sho_hn 5y ago
  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.
deleted 5y ago
[deleted]
jcelerier 5y ago
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. * https://github.com/qt/qtbase/tree/dev/src/plugins/platforms https://github.com/qt/qtbase/tree/dev/src/plugins/platforms
- badsectoracula 5y ago
  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.
  - jcelerier 5y ago
    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.
    - badsectoracula 5y ago
      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.
      - ogoffart 5y ago
IshKebab 5y ago
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.
jonathanstrange 5y ago
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.
- sharikous 5y ago
  Can't you just link HarfBuzz for that?
  - jcelerier 5y ago
    Harfbuzz partly comes from Qt's codebase IIRC
  - mwcampbell 5y ago
    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.
beowulfey 5y ago
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)! https://www.areweguiyet.com/ https://www.areweguiyet.com/ The secret, I suspect, is probably "money".
badsectoracula 5y ago
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).
- mwcampbell 5y ago
  > from personal experience working on GUIs and toolkits for decades i think are overblown) Accessibility and internationalization are really hard though, right? I'm finally doing something about the accessibility issue: https://github.com/AccessKit/accesskit https://github.com/AccessKit/accesskit Still have a long way to go though.
  - badsectoracula 5y ago
    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.
- nu11ptr 5y ago
  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.
fulafel 5y ago
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)
api 5y ago
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.
- badsectoracula 5y ago
  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.
  - sho_hn 5y ago
    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.
    - mwcampbell 5y ago
      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?
      - sho_hn 5y ago
        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.
bluGill 5y ago
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.

gbin 5y ago

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.

Kelteseth 5y ago
There is an example folder https://github.com/KDAB/cxx-qt/tree/main/examples https://github.com/KDAB/cxx-qt/tree/main/examples
- detaro 5y ago
  And the start of the "book" also explains an example: https://kdab.github.io/cxx-qt/book/getting-started/2-our-first-cxx-qt-module.html https://kdab.github.io/cxx-qt/book/getting-started/2-our-fir... Fully agreed that should be more obvious though.
  - simlevesque 5y ago
    The first comment says specifically "screenshot" but the links you and the person you replied to mentionned both have no screenshot. We want screenshots. Images of the end product GUI.
    - detaro 5y ago
      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?
    - rat9988 5y ago
      Honestly no one needs screenshot. It's not showcasing a gui framework, but a binding to an existing one. I'd go as far to say that if you need screenshot for this, you may not be their primary audience.

dotancohen 5y ago

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.

detaro 5y ago
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.
Rochus 5y ago
Whatever license the binding has, open-source Qt is only available under LGPL or GPL.
epage 5y ago
Rust uses it and so has become a default license for Rust crates. See https://rust-lang.github.io/api-guidelines/necessities.html#c-permissive https://rust-lang.github.io/api-guidelines/necessities.html#...
- dotancohen 5y ago
  I see, interesting. Thank you for bringing this to my attention.

oever 5y ago

Like the more mature <https://invent.kde.org/sdk/rust-qt-binding-generator https://invent.kde.org/sdk/rust-qt-binding-generator> this project avoids binding existing C++ code, but makes rust code available to C++/QML projects.

sho_hn 5y ago
Being familiar with your project I'm curious how this new one differentiates itself (other than being built on cxx).
- oever 5y ago
  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. Here's a talk on the idea. <https://archive.fosdem.org/2018/schedule/event/rust_qt_binding_generator/ https://archive.fosdem.org/2018/schedule/event/rust_qt_bindi...> 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.

bagavi 5y ago

Do you plan to support rust integration with pyqt?

fullstop 5y ago
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.
- nicoco 5y ago
  Fancy lasagna? Try qtpy! https://github.com/spyder-ide/qtpy https://github.com/spyder-ide/qtpy
  - foresto 5y ago
    That is the cutest project name I've seen in a while.
- brnt 5y ago
  Pyside2, or Qt for Python, is now a Qt project, and can be expected to stick around for a long time.

ogoffart 5y ago

I wonder what problems from the list apply to another existing and more mature solution: https://github.com/woboq/qmetaobject-rs/ https://github.com/woboq/qmetaobject-rs/

detaro 5y ago
Given that the last commit is by someone with the same username as you, wouldn't you know better than random HN commenters?
- ogoffart 5y ago
  Well, that's the thing. In my (biased) opinion, that crates doesn't have any of the problem mentioned. - The qmetaobject crate tries to be idiomatic rust and to be used without any C++ - As far as the user is concerned, there shouldn't be any call involving C++ - It does follow the Rust multi-threading guarantees - The License is the same as CXX-Qt - It does support plugins: https://github.com/woboq/qmetaobject-rs/tree/master/examples/qmlextensionplugins https://github.com/woboq/qmetaobject-rs/tree/master/examples... - It uses code generation via macro
  - detaro 5y ago
    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.

the__alchemist 5y ago

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.

isomel 5y ago
There are already plenty of GUI solutions for rust. All with a diverse level of polishing and convenience.
- rapsey 5y ago
  A diverse level of incompleteness you mean. Nothing comparable to Qt exists.
  - isomel 5y ago
    Exactly. But there are already bindings to Qt in different states. Let's see if this one bring anything.
- wongarsu 5y ago
  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.
  - the__alchemist 5y ago
    Yea - `embedded-graphics` is nice for embedded primatives and text.
- nu11ptr 5y ago
  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.

jokethrowaway 5y ago

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.

hda111 5y ago

Can this dynamically link to Qt to circumvent the GPL?

orra 5y ago
Dynamic linking doesn't circumvent copyright law, so it doesn't circumvent copyleft.
- Macha 5y ago
  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. [1]: https://www.qt.io/licensing/open-source-lgpl-obligations https://www.qt.io/licensing/open-source-lgpl-obligations
  - isomel 5y ago
    It's like asking "do you accept bitcoin to circumvent tax law" First of all, bitcoin does not circonvent tax law. (And linking does not circonvent GPL)
  - orra 5y ago
    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.
oever 5y ago
Qt is LGPL 3.0. Dynamically linking from close source is allowed.

mamcx 5y ago

csnover 5y ago

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.) [0] https://lib.rs/keywords/qt https://lib.rs/keywords/qt [1] https://github.com/rust-qt/ritual https://github.com/rust-qt/ritual

mockery 5y ago
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. [0] https://www.kdab.com/ https://www.kdab.com/
ogoffart 5y ago
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/ https://github.com/woboq/qmetaobject-rs/ But now I've moved on to another GUI project: Slint https://github.com/slint-ui/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.

ncmncm 5y ago

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.