ogoffart

Similar story here.

Even though our ovens actually work fine, the problem is a new competitor: OpenOven. Their oven is completely free, and on the Italian forum everyone talks about them. It has even way more buttons than ours (most don't work very well, but the community loves it).

We almost sold to MrBaguette, one of the biggest bakery chains in the world, as they wanted new oven supplier for their next generation of kitchen. Their chef tried our oven and loved it. But in the end they went with the pricier one from Corporate Oven, because some VP thought we were too small and worried we wouldn't supply them in 20 years.

one missing from that list: Slint, which i work on. runs on Linux, Windows, macOS and embedded, with app logic in Rust, C++, Python or JS.

You can use JS but it doesn't ship a browser engine, it renders with its own lightweight toolkit.

If you are looking for something similar but not limited to C++, you can check Slint out: https://github.com/slint-ui/slint/

C++ works, but compared to other languages it's often no longer the most productive choice for UI work. Modern UI code is mostly glue and state management, where fast iteration matters more than squeezing out maximum performance. And when performance does matter, there are also newer, safer languages.

For teams comfortable with C++ or with existing C++ libraries to integrate, it can of course still be a strong choice, just not the preferred one for most current teams.

Qt is still used, but I think part of the reason it is less used is that C++ isn't always the right language anymore for building GUI application.

That’s actually why we're working on Slint (https://slint.dev): It's a cross-platform native UI toolkit where the UI layer is decoupled from the application language, so you can use Rust, JavaScript, Python, etc. for the logic depending on what fits the project better.

We're actually working on a native open source cross-platform UI toolkit called Slint that’s trying to do exactly that. https://slint.dev

I wish that there was some native alternative to the Web-based everything.

I suggest Slint (https://slint.dev)

There are some desktop apps made with Slint. For example:

- WesAudio has a VST plugin for audio applications: https://slint.dev/success/wesaudio-daw

- LibrePCB 2.0, is migrating their code from Qt to Slint and should soon be released. https://librepcb.org/blog/2025-09-12_preview_of_next_gen_ui/

- krokiet: https://github.com/qarmin/czkawka/blob/master/krokiet/README...

someone has to make a native cross-platform desktop UI framework that doesn't suck

This is exactly what we're trying to do with Slint (https://github.com/slint-ui/slint ). It’s a native, cross-platform UI framework for desktop and embedded (Rust/C++/Python/JS), with no browser runtime

So in case of slint, I would check how they solved the text inputs.

Slint uses the NativeActivity by default, but it supports IME by implementing the IME support in Java in the Slint's android backend.

slintpad.com uses the wasm port to run on a browser and is not the same as when using Slint to build a "native" app, especially on mobile.

Slint does support decent text input and IME. Including text selection with the native handle. As a demo for android you can try the demo from https://material.slint.dev/ ("Download APK")

I’m curious what that showstopper bug actually was.

I was really looking forward to this feature, as it would've helped improve Rust <-> C++ interoperability.

Of course Rust can handle those use cases fine (GUIs, web browsers, and game engines).

C++ is still high on the TIOBE index mainly because it is indeed old and used in a lot of legacy systems. For new projects, though, there's less reason to choose C++.

Author of one of these "markup"-based toolkits here. I believe that Rust might not be the best language syntax to express UI. I am curious why you are so strongly against using a DSL.

This topic comes up often, so I wrote a blog post explaining why I think a DSL is a good fit: https://slint.dev/blog/domain-specific-language-vs-imperativ...

Not OP, but some users migrated from Qt to Slint and are happy with it. [https://slint.dev] (I'm one of the Slint developers.)

Slint does require using its DSL to define UIs, but I'd argue it's not really like learning a whole new language. It's not harder than learning the API surface of any other GUI framework.

I actually wrote a blog post about this exact topic, since it's a common question: https://slint.dev/blog/domain-specific-language-vs-imperativ...

Regarding Rust GUI framework, there is also Slint https://slint.dev

(Disclaimer: I'm one of the Slint developers.)

I'm one of the developers of Slint[0], a framework the should be ticking all the boxes for stable, lightweight, and native-style UIs supporting accessibility

[0] https://slint.dev

Rust, contrary to public claims, often does worse on memory safety than C++, which is a sad state of affairs.

Nonsense! Where do you get that from?

Aslo, you can make easily make linked list, it's just not a recommended data structure.

Rust claws at market share but has problems with basic stuff like doubly linked lists, WIP gccrs and memory unsafety,

Doubly linked lists aren’t that important today. Rust doesn’t need gccrs to be useful, and it gives much better memory safety than C++ without needing a GC. So I find your criticism of Rust seems a bit weak. Rust is a strong alternative to C++.

10 years ago, in another life, I was already experimenting with trying to provides feature from moc with reflections and from other macros:

- https://woboq.com/blog/reflection-in-cpp-and-qt-moc.html 2014, That was based on a previous reflection proposal

- https://github.com/woboq/verdigris : 2016, Replaces the moc by a set of macros.

What my verdigris experience shows is that it is perfectly possible to replace the moc at the cost of slightly uglier macros. And this was using C++14. I haven't look in details at the C++26 reflection, but I'm sure it would make it easier to make these macro more pretty.

Did you know about Slint https://slint.dev ? What do you think about it?

I’m actually working on an alternative called Slint => https://slint.dev

I use the the code lenses of code action feature of the LSP so that the user can start a preview. The LSP server will then open a native window on desktop.

Every time the users do some change in the code, the editor sends the document and we re-render the preview.

I use the textDocument/documentHighlight request to know when elements are being selected from the code so I can highlight them in the preview.

When selecting an element in the preview UI, my LSP server sends a window/showDocument to position the cursor at the right location. And if the user changes property or do change in the file, we do a workspace/applyEdit command with the changes.

Btw, the code is there: https://github.com/slint-ui/slint/tree/master/tools/lsp

For Slint [https://slint.dev], a (native) GUI Toolkit, I've also developed a LSP server that do live preview and editing. You can try it online at https://slintpad.com : if you click on the toolbar button to enable the right panel, you can edit the properties from the UI, and this is all done through the LSP and can be integrated in any editor that supports it.

Slint is aiming at having native looking widgets.

We're building Slint as a business. It takes a lot of time and effort to maintain and improve it. We're not looking to support users who want to use it in proprietary software and give absolutely nothing back, not even a small credit. That doesn’t feel like too much to ask. (Even the MIT license requires including a copyright notice.)

Honestly, it’s a bit sad that for some, using libraries for free isn't enough, they also expect to do so without even mentioning the project.

Since others are sharing Rust GUI libraries, I’ll mention Slint [https://slint.rs] a native GUI toolkit written Rust. It has a declarative domain specific languages, editor tools, and has been stable with no breaking API changes since 2023. I'm one of the developers.

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