<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Cxx-Qt on VisorCraft News</title><link>https://www.visorcraft.com/news/tags/cxx-qt/</link><description>Recent content in Cxx-Qt on VisorCraft News</description><generator>Hugo</generator><language>en-US</language><lastBuildDate>Tue, 18 Aug 2026 06:00:00 -0500</lastBuildDate><atom:link href="https://www.visorcraft.com/news/tags/cxx-qt/index.xml" rel="self" type="application/rss+xml"/><item><title>cxx-qt: how a Qt codebase becomes a Rust codebase without rewriting</title><link>https://www.visorcraft.com/news/2026/08/cxx-qt-how-a-qt-codebase-becomes-a-rust-codebase/</link><pubDate>Tue, 18 Aug 2026 06:00:00 -0500</pubDate><guid>https://www.visorcraft.com/news/2026/08/cxx-qt-how-a-qt-codebase-becomes-a-rust-codebase/</guid><description>&lt;p&gt;Rewriting a shipping Qt application in Rust is how you turn a working product into a two-year migration project that never quite converges, because the UI was never the problem, the logic was, and yet the rewrite always seems to start by throwing the UI away first. The question worth answering is a narrower one: how do you move the interesting code into Rust while the QML, the Kirigami pages, and the designer&amp;rsquo;s muscle memory stay exactly where they are?&lt;/p&gt;</description></item></channel></rss>