Qt Goals

2026

Three goals to present and discuss

The three goals

1. Lowering the Barrier for Contributions

Qt has a huge user base and a small contributor base. The gap is mostly process.

2. Qt Programming Languages beyond C++

A large population of Qt users sits structurally outside the Project.

3. Make Qt Feel Native Again

Qt applications now look way too different from the system native UI.

For each: why, what success looks like, a plan, who is in, and questions for the room.

Goal 1 of 3

Lowering the Barrier

for Contributions

https://qt-project.atlassian.net/browse/QTCS-40

Huge user base.

Small contributor base.

The gap is mostly process.

Where people give up

The bug reporter

Files a good bug report, and sees it sit unread.

The doc reader

Spots a typo, and finds it needs a Qt Account, a CLA, Gerrit, and often a local build.

The student

Can't tell which issues are approachable.

The designer or writer

Reads the contribution page and correctly concludes none of it is for them.

Different exits, same pattern

  • High cost for the first contribution
  • Unclear path
  • Unpredictable response

The consequences:

  • Maintainers absorb triage others could do
  • The backlog grows
  • The contributor base ages without replacement

What success looks like

Someone with relevant skills and no prior Qt involvement can find a task, complete it, and see it accepted within a week, without knowing anyone.

Success indicators

  • Documented triage workflow: fewer untriaged issues, faster first response
  • Doc-only changes possible without a local build
  • Wiki gardening to improve the quality of the content
  • Maintained newcomer task list across code, docs, triage and testing, each with a mentor (when possible)
  • Contributor guide organized by contribution type, not the tooling
  • Growth in first-time contributors, and in how many return

Several of these aren't measured today: baselines come first.

The plan: start with triage

  • A bug triage role on Jira, earned after helping with triage
  • A triage guide to lower the barrier
  • Alongside it: the newcomer task list and a mentor register (maybe on the wiki?)

Why first?

  • No infrastructure changes needed
  • Visible value in weeks
  • Earns the credibility for harder work later

The plan: then the infrastructure

  • Lighter path for doc-only changes from doc.qt.io
  • Motivation for forum participation (a badges system?)
  • Restructured contributor guide in contribute.qt-project.org
  • GSoC perhaps? Hacktoberfest? Season of Docs?

Optionally: formalize and enable the CLA on GitHub to get contributions from there into the project.

Who is needed

Needs:

  • People who know the module landscape
  • Technical writers
  • Someone who can get Jira and Gerrit configuration changed

Champion: Cristián

Contributors:

  • Samuel
  • Sze Howe (triager, doc writer, wiki gardener)
  • you?

Let's discuss

  1. What should earn the triage role, and who grants it?
  2. Which modules can offer newcomer tasks and a mentor today?
  3. What is the lightest acceptable path for a doc-only change?
  4. Which baselines can we start measuring now?
  5. CLA on GitHub: worth it, and what would it take?
Goal 2 of 3

Qt Programming Languages

beyond C++

https://qt-project.atlassian.net/browse/QTCS-42

A growing share of Qt users aren't writing C++

Inside the Project

  • PySide
  • Qt Bridges

Almost everything else is outside

These have users and maintainers, and the Project has no relationship with any of them.

Who loses?

The developer

Can't tell whether their binding is viable.

The binding maintainer

Gets no warning of breaking API changes.

Qt's API designers

Make reasonable C++ decisions without knowing which ones hurt elsewhere.

Outside not by decision,

but by absence of a channel.

The only one of the three goals that reaches people not already in Qt's orbit.

Success indicators

A discussion group, so the outputs are documents, relationships, and decisions.

  • Published survey of the binding landscape: maturity, maintainers, licensing, version coverage
  • Written position on what recognition by the Qt Project would mean, and what it wouldn't
  • Working two-way contact with at least three external binding projects
  • A bindings track at the next Contributors Summit
  • Binding impact reflected in API design guidance, in whatever form the Maintainers find workable
  • New participants arriving via their own language community

The plan

  • Public meetings with minutes, open to binding maintainers regardless of prior Qt contributions
  • Year one delivers the landscape survey and the recognition paper to the development list
  • The Summit track is the public milestone

Needs

  • PySide experience
  • Someone active in a non-Python binding community
  • Someone who knows Qt's API review practice

Champion: Cristián
Contributors: you?

Let's discuss

  1. Which three binding projects should we reach out to first?
  2. What should recognition mean, and what should it explicitly not mean?
  3. How should binding maintainers hear about breaking API changes?
  4. What form of API design guidance would Maintainers find workable?
  5. Who knows someone in a binding community we should invite?
Goal 3 of 3

Make Qt Feel

Native Again

https://qt-project.atlassian.net/browse/QTCS-22

Back in time

Qt was a great cross-platform toolkit that let developers create native-looking applications with ease.

Nowadays

Most OSes Qt supports changed their design language or HIG, and Qt applications, Widgets or QML, look way too different from the system native UI.

What can we do to make native-looking easy again?

Behind-window blur

First-party, native behind-window blur support.

Client-side decorations

First-party support, without fiddling with startSystemMove / startSystemResize.

Controls that match

Existing widgets and QQC2 controls look like the system UI design.

Eat our own dogfood

First-party Qt applications look and feel native.

Client-side decorations, out of the box

  • Custom title bars without reimplementing move and resize by hand
  • The maximize button shows Snap Layouts on hover, out of the box

Dogfooding: Qt Assistant and friends

Make sure some first-party Qt applications (e.g. Qt Assistant) look and feel like native applications.

Verify that it is still really easy to develop native-looking applications, by doing it ourselves.

Let's discuss

  1. Which platforms and design languages come first?
  2. Widgets, QQC2, or both: where is the gap largest?
  3. Which first-party app is the best dogfood candidate?
  4. What would success indicators look like for this goal?

People

  • Wang Gary (champion)
  • Tor Arne Vestbø
  • … add your name here!

Qt Goals 2026

qt-project.org