Oxidizing KDE: How, why, and why not?

Technological concepts & key points (KDE’s view on adopting Rust)

KDE overview

KDE is an international free-software community (not only a Linux desktop ecosystem). It builds major apps and platforms—such as Plasma desktop, Krita, and Kdenlive—and runs across multiple OSes (Windows, macOS, Android, etc.).

• KDE’s codebase is mostly C++
• It relies heavily on Qt and CMake

Why Rust matters to KDE

Rust’s headline feature is memory safety, but the speaker notes KDE hasn’t historically had many security issues directly tied to memory unsafety.

Key reasons Rust is still considered beneficial:

• Fewer crashes: Rust reduces crashes, though panics still occur. Not all panics are security vulnerabilities, but they remain user-visible problems.
• Ergonomics & consistency: Rust is described as having more consistent API design and applying “modern C++” principles with better defaults.
• Tooling & dependency ecosystem: Rust tooling/build/dependency management and the availability of crates make Rust attractive for new contributors.

Interoperability: integrating Rust with C++/Qt in KDE

Problem framing

KDE does not plan to rewrite its large C++ base in Rust immediately.

Baseline interop approach (C ABI → C++)

• Rust can interoperate with C via a C ABI
• C++ can be reached indirectly since C++ descends from C
• However, crossing the bridge for higher-level types is tedious:
  • Rust types like Option, Vec, Box
  • C++ types like unique_ptr
  • Such types often need to be decomposed and reconstructed across the C ABI boundary

Solution: cxx and related KDE crates

KDE’s approach emphasizes higher-level tooling on top of the C ABI.

• cxx crate
  • Provides “high-level interoperability” between Rust and C++
  • Still uses C ABI under the hood
  • Automates breaking/building of conceptual types
  • Aims for safer bindings
• cxx-qt crate
  • Created by KDE colleagues
  • Extends cxx ideas to Qt types for more natural interaction
• CXX KDE framework bindings
  • KDE also creates additional wrappers/bindings (“CXX KDE frameworks create”) to connect Rust to internal KDE libraries

Exposed types in Rust↔C++ bridges: shared vs opaque

CXX-style bridging can expose types in two main ways:

• Shared structs
  • Rust and C++ both have struct representations
  • Works well when the types translate cleanly
• Opaque types
  • Rust can’t pass values directly
  • Requires indirection (references/pointers/boxes)
  • Feels less “Rust-like” and can reduce ergonomics

Key technical pitfall: “trivially relocatable” types

To get value-like behavior, KDE relies on trivially relocatable / trivially relocatable types (copy/move semantics at the byte level).

However, this is described as not fully guaranteed and tricky in practice, including:

• C++ operator definitions and ABI/security details can cause problems
• Polymorphic types/vtables
  • On some ABIs (e.g., ARM64 EABI mentioned)
  • Vtables may involve security authentication
  • This prevents trivial relocation, called out as a major pitfall

There is also ongoing work in the C++ standards community to define “trivial relocatability” formally, and the speaker hopes this will make the bridge more reliable.

Other unsolved/hard interoperability challenges

• Generic programming mismatch
  • Rust traits vs C++ templates don’t map cleanly through cxx
  • Example: a “vector-like” type may require explicit specialization per element type rather than fully generic behavior
• Async bridging complexity
  • Difficulty integrating Rust async with C++ async tooling (e.g., Tokyo event loop, coroutines, etc.)
• API “idiomaticity” drift
  • Rust-side and C++-side APIs may become shaped by bridge constraints rather than staying fully idiomatic
• Concerns about upstream cxx momentum
  • Upstream cxx development is described as somewhat dormant
  • The speaker suggests more community involvement beyond single-maintainer development

Where Rust fits best in the KDE architecture

Where it’s not ideal

Rust may “get in the way” for high-level UI/application glue, such as:

• UI element placement
• Layout composition

Where it’s most useful

Rust is viewed as a good fit for lower-level tasks:

• File parsing
• File I/O
• Data processing (“data grunching”)
• Serialization/deserialization

Gradual rewrite realities

A function/class-by-function/class rewrite is hard because outcomes depend on how well KDE’s interfaces map onto what the bridge supports.

Existing Rust usage examples inside KDE

Examples mentioned include:

• Ad-blocking in KDE PIM using an ad-blocking crate (block lists/management)
• HTML parsing using an HTML parsing crate
• A newer CSS-related need handled using a CSS crate (noted as coming from the “server project”)

Crates.io and dependency management concerns

• Crates.io is praised for ease: cargo-based dependency integration is described as “one cargo away.”
• Risks include:
  • “Node module syndrome”
    • Dependency trees can become extremely deep via transitive dependencies
    • Teams may not have audited them (unclear stability/security policies)
  • Distribution/vendor tension
    • Linux distributions often prefer their own packaging model (shared libraries, centralized patch/versioning, coordinated vulnerability tracking)
    • This conflicts with Rust/Cargo’s approach, where responsibility trends toward upstream application developers
  • Crate quality/stability variability
    • Even if a crate exists, it may not meet project constraints
    • Ecosystem instability and inconsistent quality are concerns

Build systems integration: Cargo + CMake in KDE

• Cargo is excellent for pure Rust projects
• KDE’s C++ ecosystem is CMake-based
• KDE uses corrosion to build Rust code via CMake integration and link Rust artifacts into C++ projects

Installing/distribution problem with pure Cargo

Cargo builds binaries, but KDE must also package/install auxiliary files such as:

• man pages
• icons
• desktop files
• AppStream metadata

Cargo doesn’t fully handle that packaging flow, so KDE relies on CMake-based tooling/packaging so distributions can consume it consistently.

Social/organizational impact

Adding Rust increases:

• Technical complexity
  • Learning interop concepts and bridging constraints
• Social complexity
  • Contributors may avoid Rust if it complicates the workflow, potentially leading to community fragmentation

Benefits

• Attracts contributors who:
  • already use Rust professionally, or
  • want to work on KDE without spending free time writing large amounts of C++
• Encourages cross-community learning between the Rust community and KDE’s large-scale open-source experience

Reviews/guides/tutorials mentioned

The talk provides practical guidance-by-example rather than a linear step-by-step tutorial, including:

• Choosing interop layers (cxx, cxx-qt, KDE bindings)
• Understanding CXX type exposure modes (shared structs vs opaque)
• Interoperability pitfalls:
  • trivial relocatability
  • vtables/ABI security
  • generics
  • async
• Integrating build/distribution pipelines:
  • corrosion
  • auxiliary file packaging requirements

Main speakers / sources

• Nicholas Fella (KDE)
  • Speaker; software platform engineer at KDEV
  • Describes KDE’s C++/Rust integration approach and interop tooling
• Leon (KAB / CXX-Qt maintainer)
  • Responds regarding maintaining/forking cxx-qt
  • Raises concerns about potential ecosystem splitting