ogoffart

Hi, I'm one of the developers behind Slint. Sorry to hear Slint didn't work out for you. We’re aiming for a great developer experience, so I’d love to understand what specifically went wrong.

> Qt level GUI framework

Trying to bring that with Slint: https://slint.rs

> Rust could get a rock solid portable GUI toolkit that doesn't rely on a webview [...], but it's not there yet.

What would you say is missing in Slint?

> probably not much harder than wrapping Qt, to be honest

There are already Qt bindings for rust (cxx-qt, qmetaobject-rs). What's missing from these?

Slint is free for desktop.

Slint is under three licenses: GPL, or royalty-free on desktop/mobile, or paid for embedded. So you only have to pay if you sell hardware.

I actually wrote Rust bindings for Qt a while back: https://github.com/woboq/qmetaobject-rs/. I'm curious to see how Qt's own take with Qt Bridges will work out. That said, I’ve since moved on and now work on Slint [https://github.com/slint-ui/slint]

Slint was created with the same idea as what drives "Qt Bridges". We made a UI toolkit that is language-agnostic from the start. Slint uses its own UI language (inspired by QML), and gives you first-class, idiomatic APIs in Rust, C++, Pyhton, and JavaScript. And a clean separation between UI and business logic.

Off-topic, but the idea of "colored functions" from the "What Color is Your Function" article doesn't apply to Rust's async/await. That article is about JavaScript before it had async/await, when it used callbacks.

In Rust, you can call async functions from normal ones by spawning them on the executor. The .await syntax isn't as painful as dealing with callbacks and closures in JavaScript. Plus, if you call an async function incorrectly, Rust's compiler will catch it and give you a clear error message, unlike JavaScript, where bad function calls could lead to unpredictable behavior. The premises of the article don't apply, so Rust's async/await doesn't introduce the same "colored function" issues.

(See also https://without.boats/blog/let-futures-be-futures/ )

Just wanted to mention that Slint has had a stable API for over two years now. (We released Slint 1.0 more than two years ago and have kept things backward compatible since) So stable GUI APIs in Rust are possible. If you're looking for something solid to build on, Slint might be worth a look.

I wrote a language server too, and I also went with "-lsp" naming because it's way more recognizable. "LSP" is kind of a brand. If you look at the list at https://microsoft.github.io/language-server-protocol/impleme... a lot of them are named -lsp.

You can have a tree view Slint. There is one example in https://github.com/slint-ui/cargo-ui And also in https://github.com/LibrePCB/LibrePCB/pull/1504

If you're looking for a stable GUI toolkit, there is Slint

> This is going to silently break so much existing code

The code was already broken. It was an undefined behavior.

That's a problem with C and it's undefined behavior minefields.

> Prior to the current version of Rust it was impossible to access methods on `Foo` when a `&dyn Bar` was passed.

This has been working since Rust 1.0, I think:

    trait Foo {
        fn foo(&self);
    }
    trait Bar : Foo {}

    impl Foo for () {
        fn foo(&self) { println!("Hello") }
    }
    impl Bar for () {}

    fn xxx(x: &dyn Bar) {
       x.foo();
    }

    pub fn main() {
        xxx(&());
    }

> With the current beta version you can upcast

Right. Now you can convert from `&dyn Bar` to `&dyn Foo` which wasn't possible before.

I'm developer of Slint and I'm glad to see Slint mentioned. I want to clarify that we're not trying to mimic the web. We have a great vision for the desktop integration, but we unfortunately have limited resources. Our team is fairly small and we are mainly working with paying customers to pay the bills, which are mostly in embedded space at the moment. I agree with your points, and while there’s still a lot to do, I hope Slint can become a strong option for building powerful complex desktop applications.

Awesome project! Really cool to see that the UI is built with Rust and Slint, the GUI framework I’m working on. https://github.com/slint-ui/slint

> I wonder if someone could make a decent cross-platform GUI toolkit to save us from the horribly slow Electron-hell we've carved out for ourselves.

https://github.com/slint-ui/slint

I tried once to contribute a fix to be able to use the track-pad on my laptop many years ago. But it was not accepted as the maintainer claimed it was an problem in userspace that did not process out of order events correctly. Despite none of the other drivers sent the events out of order. I had no intention to fix the problem on X11 (the only userspace for this at the time), so I used the patched kernel driver locally until I stopped using that laptop. https://bugzilla.kernel.org/show_bug.cgi?id=43591 https://lore.kernel.org/all/1340829375-4995-1-git-send-email...

Even without auto you have the problem.

    return foo().bar();

No `auto` and you still don't know the return type of foo. And knowing the type might not be the only reason you'd want an IDE anyway. What is `foo()` doing? I want to be able to easily jump to the definition of that function to verify that the assumption taken by the calling function are correct.

I've been using #pragma once in my C++ libraries for a decade and nobody ever reported any problem with that. I did get bug report about using perfectly standard C++ features that were not properly implemented in some compilers.

> the same include file is accessible under different path names (granted, that's a very esoteric scenario)

And most likely a build system problem anyway if, say, different versions of the same library get included in your build.

You might want to give Slint a try. It's a cross-platform UI framework that supports C++, Rust, JS, and Python. https://slint.dev

It's also possible to use JS (or TypeScript) on the desktop, without having the need for a browser or a webview. That's for example what we're trying to do with Slint https://slint.dev Then you get the good part of javacript for your application logic, without the bloat and attack surface of a browser.

Here is another small project to revive the car thing with a clone of the previous UI written in Rust: https://devpost.com/software/car-thang

I've observed it has become much better on my repository over the past few years. Discussions took a while to be adopted and I have to guide users to discussions through the CONTRIBUTING.md and issue template. For the few questions that still comes in the issues, i'm immediately converting them into discussions.

I often edit the title and description of issues.

I usually let the original content after a

### Original message

...

So that's a fork of a ~10 years old fork of Qt. Copperspice originally forked, in part, because Qt was not close enough to the C++ standards, and now this (outdated) GUI library is being forked because they make use of a 4 years old C++ standard. Someone should fork LsCs to add support for mobile or new C++ standard. Looking forward to see this happen in 10 years (/s)

Yes, we'd like to improve on that: https://github.com/slint-ui/slint/issues/4128

There are 3 license: 1. GPL 2. Royalty-free (free of charge for desktop) 3. Paid license (which we hope is less constraining than the Qt commercial one)

(Shameless plug) If you're looking to go away from Qt, you can check out Slint https://slint.dev Being inspired from QML, Qt users should feel at ease. The license model is hopefully less constraining than the Qt one.

Some crates are better than other.

For Slint (Another GUI toolkit in Rust), we try to keep our API as stable as possible for as long as possible. We use other crates behind the scene such as winit and co., but we don't expose them in our public API, and we take care of the burden to update them.

Why do you think this is?

Some reason I can think of:

- Can't update the compiler (eg, porting the code base to the new compiler is too complicated)

- No compiler support for the new standard that target a specific platform that one still want to support.

- Too much work to update the whole code base to work with the new standard.

- A 3rd party library is not supporting new standard yet.

- The team is reluctant to have to learn new technologies.

Some are somewhat valid reason, some are less, some are indication of deeper problems.

(P.S: My C++ code base is using C++20. Didn't move to C++23 yet because I think some customers might not be ready for it yet for one of these reasons, but I'm going to push for it at some point.)

Other editors have kind of standardized it to associate a language to a command to run and communicate trough the stdout/stdin. Why do vscode need to be more complicated?

(even this association could be done with a local DB similar to mime types if we wanted to simplify)