Video summary

Language Bindings: The Future of KDE?

Main summary

Key takeaways

Technology

Tech/product focus: “Language Bindings: The Future of KDE?”

Nico’s talk argues that KDE should grow beyond C++-only development by using language bindings and interoperability, primarily focusing on Rust and Python (rather than replacing C++ outright).

KDE codebase + why a language change is considered

KDE has ~15 million lines of code, mostly in C++, with QML as a runner-up.

Reasons given for staying cautious about C++ as the primary community language include:

  • Complexity and many corner cases
  • “Foot guns” (especially around memory management, lifetimes, out-of-bounds/user-after-free), which can lead to crashes and potential security vulnerabilities
  • Ecosystem/tooling fragmentation across compilers and platforms
  • Some libraries (e.g., Qt) don’t always integrate smoothly with the broader C++ ecosystem
  • Community challenge: attracting newcomers is getting harder if the primary language remains C++

Proposed solution: Rust for safety + performance, with C++/Rust interoperability

Why Rust is compelling for KDE

  • Memory safety built into the language, reducing common classes of C++ bugs
  • Better language design defaults and improved semantics (often compared with modern C++)
  • A more consistent dependency ecosystem (crates)
  • KDE already uses Rust in multiple places, enabling incremental adoption

Interop approach: C++ ↔ Rust via bindings

Raw C FFI for C++ abstractions is considered imperfect for KDE’s needs. KDE discusses:

  • CXX: provides high-level interop between Rust and C++ (two-way calling) while minimizing unsafe glue work
  • CXXQ: extends CXX to understand Qt/QML concepts (Qt types/abstractions), but it does not expose the full Qt API to Rust yet

Build-system integration: CMake + Cargo

  • KDE uses CMake; Rust uses Cargo
  • corrosion: helper tooling to integrate Rust builds into KDE’s CMake workflows

Where Rust is already used in KDE (examples)

  • Angelfish (mobile web browser) and parts of KDE PIM
    • Use an external Rust crate for blocking lists / content blocking
  • KDE PIM HTML parsing
    • Positioned as complex and security-sensitive, making Rust a natural fit
  • Konversation (and other component referenced via “Union”)
    • Uses a Rust library for CSS parsing, wrapped into C++ via CXX/corrosion

Theme: current Rust usage tends to avoid deep KDE API interop; as adoption grows, more bindings are expected.

KDE Framework Rust bindings: CXXQt (“CXXQ frameworks”)

Nico describes CXXQt (from Daran during Google Summer of Code) as building on CXX/CXXQ to expose selected KDE Frameworks APIs to Rust.

Covered areas include:

  • KCoreAddons
  • KIO? (not explicitly; but KIO workers are mentioned later)
  • KXmlGui
  • KCrash
  • KConfigWidgets / KConfig
  • KIconThemes
  • KCMutils
  • (and additional cited “parts of …” modules)

Practical things Rust bindings enable

  • “Basic application setup” pieces:
    • Application identity/metadata (KAboutData)
    • Developer lists
    • Translations
    • Opt-in crash handling
  • A direction for system settings:
    • Potentially QML + Rust backend (UI is often QML with a C++ backend today)
  • A stated goal/open merge request:
    • Add glue to write KIO workers in Rust to reuse crates and improve low-level file operations

Rust tradeoffs acknowledged

  • The borrow checker can be harder for newcomers; code can feel more rigid
  • Qt support isn’t complete:
    • CXXQt/CXXQ covers some basics, but Qt as a UI layer is not fully ready
    • Therefore, Rust may be a poor choice for high-level “push buttons around a layout” UI glue
  • Rewrites aren’t automatically better:
    • Even with security/performance advantages, rewriting can be costly and may increase interface complexity

Why Python is also key: easier for KDE app-layer glue

Nico argues Python often fits KDE’s application/glue layer better than Rust:

  • Python is widely known, approachable, and cross-platform
  • It has a mature dependency ecosystem
  • KDE’s Qt/Python binding stack exists:
    • PyQt / PySide via “Pyite” (Qt for Python)
    • Shiboken for binding generation
  • Google Summer of Code work revived the Python bindings idea for KDE Frameworks using Qt for Python (PyQt/PySide ecosystem) rather than other binding tech

What Python bindings cover (examples listed)

Python bindings were said to exist for many KDE Frameworks/modules including:

  • KCoreAddons
  • GuiAddons
  • WidgetsAddons
  • Notifications
  • KXMLGUI
  • KStatusNotifierItem
  • KUnitConversion
  • KJobWidgets

Motivation for bindings: “KDE-flavored” apps in Python

Python bindings enable building glue to transform plain Qt/Cute apps into more fully KDE-integrated apps (KDE metadata, widgets, jobs, etc.).

Python remaining challenge: distribution

  • KDE Python packages may not yet install easily via expected tooling like pip
  • Need/improvement: packaging so Python developers can install KDE integration the way they’re used to

Overall recommendation: C++ stays; Rust and Python take different roles

  • Neither Rust nor Python replaces C++ soon, since KDE has too much existing C++ code.
  • Suggested division of labor:
    • Python: topmost app layer / glue layer near QML and/or Qt widgets
    • Rust: lower-level tasks (file parsing/handling, input handling), especially where safety/security matters or where there’s a strong Rust crate with no C++ equivalent

Caution about “wrapping everything”

Bindings are useful when:

  • Functionality is exclusive to KDE, or
  • Types are part of other public APIs and wrapping requires dependent KDE APIs (e.g., configs that require KConfig-related bindings)

But blindly wrapping/replacing might be inferior—for example, skepticism about replacing existing KDE calendar/event logic with random third-party parsers.

Community/social risks + mitigation (discussion portion)

Nico raises concerns beyond pure technology:

  • Mixing multiple languages could jeopardize technical consistency and contributor mobility across KDE projects
  • Binding creation is hard; not all API concepts translate well between languages
  • Risk of social fragmentation:
    • If Rust/Python adoption creates “written in X language only” barriers, newcomers may opt out
  • Needs strong documentation:
    • How to create bindings
    • How to package/distribute them
    • How interop works for contributors

Suggested mitigation approach (from Q&A)

  • Emphasize education and low-barrier guides for learning Rust interop and Rust-in-KDE workflows
  • Show concrete benefits (e.g., fewer crashes)
  • Ensure community infrastructure/tools are not hostile to newcomers

Community tooling platform concern (GitHub vs Discord/etc.)

The discussion touches on how Rust/Python communities collaborate (GitHub vs Discord) and suggests:

  • Offering modern alternatives like Matrix
  • Avoiding hard constraints that limit collaboration

A “product first” framing is used: tools should support contribution workflows and ultimately attract developers.

Speakers / sources (mentioned at end)

  • Main speaker: Nico
  • Other referenced speakers/sources during the talk/Q&A:
    • Christian (earlier talk; context on binding approach/challenges)
    • Ian (mentions regarding “Union” and CSS parsing library usage)
    • Daran (developed CXXQt during Google Summer of Code)
    • Manuel (helped revive KDE Python bindings via Google Summer of Code)
    • Alex / “Manuel was working…” (contextual: Manuel led revival of the Python bindings idea)
    • Attendees asking questions during Q&A (not named)

Original video