News for hackers. Stuff that matters.

ogoffart

Re:Development statistics for the 7.2 kernel on Saturday October 17, 2026 @02:10PM (#50133504)
I have noticed the same on my project.

The agent helps a lot to fix bugs. Just point the agents at the bug reports. They do the reproduction, debugging and fixes. We "just" have to review. (Sometimes ask more details and tell we'd prefer another approach.) This makes bug fixing much faster and automated.

And at the same time, it seems we get less bug reports to our library. I think user just use their agents to code, and agents don't report bugs, they just work it around somehow.

So overall, the open bug count is decreasing. Which somehow feels good.

On the other hand, we get a lot of PR made by other's people agents, which can be a bit overwhelming when it's just a huge code drop. We can't easily review that.

There is also Slint that'd fir perfectly. Others have built game launcher with it as well
Re:Rust Is Tier-1 Language at Microsoft on Friday September 11, 2026 @06:36AM (#49656141)
Slint ?
Re:Ask HN: Any true alternatives to electron JavaScript? on Friday August 28, 2026 @01:19PM (#49481704)
There is Slint - https://github.com/slint-ui/slint/

- UI renders natively (without a browser)

- Slint uses a declarative UI that should be intuitive to use for developers / designers / agents.

- Can be interfaced from different languages such as Rust / JS / TS / Python

(disclaimer, I am working for Slint)

Re:Half-Baked Product on Friday July 03, 2026 @07:21AM (#48773704)
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.

Re:Deno Desktop on Monday June 22, 2026 @11:30AM (#48631625)
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.

Re:Native all the way, until you need text on Sunday May 17, 2026 @10:22AM (#48169175)
If you are looking for something similar but not limited to C++, you can check Slint out: https://github.com/slint-ui/slint/
Re:The Codex App on Tuesday February 03, 2026 @05:45AM (#46869270)
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.

Re:The Codex App on Tuesday February 03, 2026 @04:04AM (#46868464)
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.

Re:The Codex App on Tuesday February 03, 2026 @03:57AM (#46868421)
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
Re:Web-based image editor modeled after Deluxe Paint on Monday January 26, 2026 @10:39AM (#46766976)
> I wish that there was some native alternative to the Web-based everything.

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

Re:High-Level Is the Goal on Saturday January 17, 2026 @05:45AM (#46656968)
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...

Re:High-Level Is the Goal on Saturday January 17, 2026 @05:34AM (#46656928)
> 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

Re:Build Android apps using Rust and Iced on Monday December 22, 2025 @11:26AM (#46355489)
> 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.

Re:Build Android apps using Rust and Iced on Monday December 22, 2025 @11:14AM (#46355343)
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")

Re:Is C++26 getting destructive move semantics? on Friday November 21, 2025 @11:44AM (#46006105)
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.

Re:Is C++26 getting destructive move semantics? on Friday November 21, 2025 @11:39AM (#46006059)
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++.

Re:Rust's TUI Revolution on Thursday November 06, 2025 @02:43AM (#45832554)
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...

Re:Qt Group Buys IAR Systems Group on Monday October 20, 2025 @03:31PM (#45648158)
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.)
Re:Upcoming Rust language features for kernel development on Thursday October 16, 2025 @07:03AM (#45603918)
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...

Re:Upcoming Rust language features for kernel development on Thursday October 16, 2025 @06:25AM (#45603673)
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

Re:C++ Reflection and Qt MOC on Monday October 13, 2025 @05:52AM (#45566590)
> 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.

Re:C++ Reflection and Qt MOC on Sunday October 12, 2025 @04:18PM (#45561522)
> 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++.

Re:C++ Reflection and Qt MOC on Sunday October 12, 2025 @01:06PM (#45559808)
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.

Re:We rewrote the Ghostty GTK application on Friday August 15, 2025 @10:19AM (#44912747)
Did you know about Slint https://slint.dev ? What do you think about it?
Re:Bypassing Google's big anti-adblock update on Sunday July 13, 2025 @03:31AM (#44548268)
I’m actually working on an alternative called Slint => https://slint.dev
Re:Code⇄GUI bidirectional editing via LSP on Wednesday July 02, 2025 @06:20AM (#44441964)
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

Re:Code⇄GUI bidirectional editing via LSP on Tuesday July 01, 2025 @05:17PM (#44438081)
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.

Older »