feat: Add Qt bindings by d2weber · Pull Request #76 · chatmail/yerpc

d2weber · 2026-06-12T14:51:26Z

This adds qt binding generation. It uses the json parsing from qt. A transport-implementation is needed to use it, similar to typescript. I have an implementation for deltachat-cffi but i think it would go in the chatmail-core repo.

Click to expand the CffiTransport implementation

class CffiTransport : public QThread, public Transport {
    Q_OBJECT

public:
    explicit CffiTransport(dc_accounts_t* accounts, QObject* parent = nullptr)
        : QThread(parent)
        , jsonrpc_(dc_jsonrpc_init(accounts))
    {
        if (!jsonrpc_) std::abort();
        start();
    }

    virtual ~CffiTransport() override {
        done_ = true;
        // Unblock dc_jsonrpc_next_response by sending a dummy request
        if (jsonrpc_) dc_jsonrpc_request(jsonrpc_, "{\"jsonrpc\":\"2.0\",\"id\":0,\"method\":\"get_system_info\"}");
        wait();
        QMutexLocker lk(&mu_);
        for (auto& [id, prom] : pending_) {
            prom.set_value({{}, "Transport destructed", -32060});
        }
        pending_.clear();
        if (jsonrpc_) dc_jsonrpc_unref(jsonrpc_);
    }

    virtual std::future<Result<QJsonValue>> send(const QString method, const QJsonValue params) override {
        uint32_t id = next_id_++;
        QJsonObject envelope{
            {"jsonrpc", "2.0"},
            {"id", static_cast<qint64>(id)},
            {"method", method},
            {"params", params},
        };

        std::promise<Result<QJsonValue>> prom;
        std::future<Result<QJsonValue>> fut = prom.get_future();

        {
            QMutexLocker lk(&mu_);
            pending_[id] = std::move(prom);
        }

        QByteArray json = QJsonDocument(envelope).toJson(QJsonDocument::Compact);
        dc_jsonrpc_request(jsonrpc_, json.constData());
        return fut;
    }
protected:
    void run() override {
        while (!done_) {
            char* raw_json = dc_jsonrpc_next_response(jsonrpc_);
            if (!raw_json) {
              break;
            }
            QByteArray json{raw_json};
            dc_str_unref(raw_json);
            if (done_) break;

            QJsonObject obj = QJsonDocument::fromJson(json).object();

            if (!obj["id"].isDouble()) {
              qCritical() << "No valid rpc id in" << QString{json};
              continue;
            }
            uint32_t id = static_cast<uint32_t>(obj["id"].toInt());

            std::promise<Result<QJsonValue>> prom;
            {
                QMutexLocker lk(&mu_);
                if (auto nh = pending_.extract(id)) {
                  prom = std::move(nh.mapped());
                } else {
                  qCritical() << "Could not map response" << QString{json};
                  continue;
                }
            }
            prom.set_value(parseResult(obj));
        }
    }

private:
    dc_jsonrpc_instance_t* jsonrpc_;
    QMutex mu_;
    std::atomic<uint32_t> next_id_{1};
    std::atomic<bool> done_{false};
    std::unordered_map<uint32_t, std::promise<Result<QJsonValue>>> pending_;
};

I created a hopefully generally useful TypeInfo type, which can be created from TypeDef::SHAPE. This should allow easier future expansions for other (C-like) languages.

Future improvements: Add docs for generated types. Currently only the rpc methods themself are documentd.

Sidenote: I discarded an ealier draft to create bindings which tried to first implement json parsing on the C-layer with a swap-able json-parser implementation (to support both cjson and qtjson). Then C++ wrappers were added ontop of the C-Layer. But writing safe C code and interop is hard and the generated code was quite involved and hard to understand, all in all it got quite complicated. This approach is much simpler, it just works for qt, but the generated code is straight forward.

Sidenote 2: I also took a look into https://facet.rs/ as a replacement for typescript-type-defs derive(TypeDef). It is an extensible reflection framework and an alternative to serde. https://docs.rs/facet-typescript could in theory replace our typescript generation. I did not investigate further because we'd have to either have to switch to use facet also for json de-/serialization or we'd have to duplicate all the #serde(..) annotations in deltachat-jsonrpc. (Facet is probably slower at runtime than serde.) The nice thing about typescript-type-def is that it reuses the serde annotations.
Another related advencement is reflection and comptime in rust which might make the derives superfluous all together one day.

d2weber · 2026-06-13T07:51:38Z

I converted to draft because I want to first settle the corresponding usage in deltatouch, see https://codeberg.org/lk108/deltatouch/pulls/269 and chatmail/core#8330

Simon-Laux · 2026-06-26T14:23:38Z

Sidenote 2: I also took a look into https://facet.rs/ as a replacement

That facet package/repo allows LLM usage (https://github.com/facet-rs/facet/tree/main/.claude) which may or may not be a bad sign for a core dependency.
Also, serde is basically the standard in the ecosystem, so I wouldn't want to switch to something that is less proven.

There is a feature request for supporting 1password's typeshare crate: #58, I think that may be interesting to explore for generating types for other languages.
The other idea was to use the OpenRPC spec to generate all bindings, but OpenRPC was not a mature/clear/good as I and others hoped. And generators for other languages were still in a very early or non-existent state at the time.
https://github.com/chatmail/dcrpcgen is our attempt at writing a code generator for python and go from the OpenRPC spec.

Move Method to module Add qt types generation Generate qt methods

link2xt

Have not looked at yerpc/src/qt.rs and yerpc/src/type_info.rs yet.

Generation of bindings are not really tested, but adding C++ tests in CI is likely not easy, so as long as DeltaTouch is using it we can probably merge it somewhat quickly if https://codeberg.org/lk108/deltatouch/pulls/269 is already using it (other than replacing all calls) and there are no problems discovered.

link2xt · 2026-08-21T14:08:24Z

+        ));
+        gen_methods_qt.push(quote!(
+                let args = vec![#(#gen_args),*];
+                let method = Method::new(#ts_name, #rpc_name, args, #gen_output, #is_notification, #is_positional, #docs);


ts_name should probably be renamed to something like camel_name since it is used for Qt as well now. As far as i understand it is accidental that Qt and TypeScript both use camel case.

Good point! I also updated the field name in Method accordingly 546f1f9

link2xt · 2026-08-21T14:37:03Z

+
+template<typename T>
+struct [[nodiscard]] Result {
+    T result;


A comment saying that this is the default value of T in case of error would be nice here as valueOrDefault implementation seems to depend on it.

You mean sth like: /// Value contained in the result. In the case of an error this is a default constructed T

Thinking about this a bit more: For the docs in valueOrDefault to be true ("If the result is an error [...] returns a default-constructed T.") I should probably just return T() in valueOrDefault. Let me know if you'd like it.

link2xt · 2026-08-21T14:48:00Z

+    QJsonObject err = val["error"].toObject();
+    if (err.isEmpty())
+      return {{}, "Invalid error in response: " + QJsonDocument(val).toJson(QJsonDocument::Compact), -32700};
+    return {{}, err["message"].toString(), err["code"].toInt()};


If there is no code (should normally not happen since there is an error message), this returns QJsonValue::Null (according to https://doc.qt.io/qt-6/qjsonobject.html#operator-5b-5d) and will evaluate to 0.

Maybe makes sense to convert it to int above and if it is 0, return custom error (also to fail if error code is 0, so we don't accidentally treat the default value as the real return value in this case).

Good point, thanks! I changed the check to !error_message.isString() || error_code == 0 b67cde9

link2xt · 2026-08-21T14:50:04Z

+class Transport {
+public:
+    virtual std::future<Result<QJsonValue>> send(const QString method, const QJsonValue request) = 0;
+    // virtual void send_notify(const QJsonValue request) = 0; not implemented


Can probably be simply removed? If someone decides later to implement yerpc support for notifications, then they will add a way to clients somehow.

Done: 1f77c32

link2xt · 2026-08-21T15:06:22Z

+  if (val.contains("error")) {
+    QJsonObject err = val["error"].toObject();
+    if (err.isEmpty())
+      return {{}, "Invalid error in response: " + QJsonDocument(val).toJson(QJsonDocument::Compact), -32700};


Just a comment: this is apparently still the standard way for C++ to initialize this kind of structures. "Designated initializers" ({.result = ..., error_message = ...) are only supported since C++20 (and DeltaTouch currently uses C++11 and maybe C++17 with the PR switching to these bindings).

Otherwise there is even std::expected to map results directly, but only since C++23. Don't know how good is the support for it currently and if DeltaTouch can switch to it.

Yes DeltaTouch would be using C++17. Because we still want to support Ubuntu Touch 20.04 we don't have a recent enough GCC version for newer C++ versions than C++17.

link2xt · 2026-08-21T15:43:25Z

@@ -0,0 +1,326 @@
+use typescript_type_def::type_expr as ts;


note: Somewhat unexpected that this module that is generic depends on something having "typescript" in it, but as far as i understand this is only because the types in JSON are essentially JavaScript types and this has nothing to do with typescript bindings here.

Co-authored-by: l <link2xt@testrun.org>

link2xt

Looks good, i think can be merged already so it can be used in DeltaTouch.

link2xt · 2026-08-24T14:25:05Z

+            }
+            .to_owned(),
+            TypeInfo::Optional(o) => {
+                format!("std::optional<{}>", o.qt_type())


A note for other reviewers, from someone not familiar with Qt: it looks like there is no QOptional or anything similar, so std::optional type is expected here:
https://stackoverflow.com/questions/33736172/does-qt-have-its-own-boostoptional-alternative

link2xt · 2026-08-24T14:27:12Z

+    String,
+    Optional(Box<TypeInfo>),
+    Array(Box<TypeInfo>),
+    Map(Box<TypeInfo>),


Not obvious from the type: the keys are always strings. A documentation comment saying that the type is the type of values could be helpful here.

link2xt · 2026-08-24T15:44:17Z

+    writeln!(
+        output,
+        r#"
+inline QJsonValue toJson(const {ty} &o) {{ return static_cast<double>(o); }}


Another note: QJsonValue has no types for integers other than double: https://doc.qt.io/qt-6/qjsonvalue.html#Type-enum
This is also the reason for int53 types in Telegram APIs, 53-bit IDs are safe to store in double, but if they get larger then they may not be represented exactly.
This is a bit dangerous if used to represent something that may actually get larger than 53-bit, e.g. maybe file sizes etc.

d2weber mentioned this pull request Jun 12, 2026

Generating as #[test] causes rebuild #77

Closed

d2weber marked this pull request as draft June 13, 2026 07:48

link2xt mentioned this pull request Jun 13, 2026

feat: Generate qt jsonrpc bindings chatmail/core#8330

Draft

1 task

feat: Add qt json bindings

48f200f

Move Method to module Add qt types generation Generate qt methods

d2weber changed the title ~~Add Qt bindings~~ feat: Add Qt bindings Jul 16, 2026

d2weber force-pushed the qt_bindings branch from 9e4cfb9 to 48f200f Compare July 16, 2026 06:40

d2weber added 3 commits July 16, 2026 08:49

fixup merge

8cc27cd

rename write_qt_bindings

ba7aead

cleanup

cf3487c

d2weber marked this pull request as ready for review July 16, 2026 16:13

cleanup

f528902

d2weber requested a review from link2xt August 19, 2026 18:02

link2xt reviewed Aug 21, 2026

View reviewed changes

d2weber and others added 6 commits August 21, 2026 19:21

Rename ts_name to rpc_name_camel

546f1f9

Fix typos

8b5c79b

Make default initialized Result safe

4d81db6

Parse result more conservatively

b67cde9

Remove commented out virtual void send_notify

1f77c32

Use brace initializer

a3d6cdb

Co-authored-by: l <link2xt@testrun.org>

link2xt approved these changes Aug 24, 2026

View reviewed changes

Uh oh!

Uh oh!

Conversation

d2weber commented Jun 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

d2weber commented Jun 13, 2026

Uh oh!

Simon-Laux commented Jun 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

link2xt left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

link2xt left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

d2weber commented Jun 12, 2026 •

edited

Loading

Simon-Laux commented Jun 26, 2026 •

edited

Loading