How To Make KDE Apps Look Normal On Gnome With The Adwaita-Qt theme

You’re happily living the GNOME life: clean panels, tidy spacing, and a design language that says,
“I have my life together” (even if your Downloads folder says otherwise). Then you open a KDE/Qt appmaybe
Okular, Krita, Kdenlive, or Dolphinand suddenly your desktop looks like
it’s hosting a costume party where Qt showed up dressed as “Generic 2009 App.”

The good news: you can usually make KDE apps blend in with GNOME using a combination of
Adwaita-Qt (for the widget look) and QGnomePlatform (for GNOME integration like fonts and icons).
The even better news: once it’s set up, your KDE apps stop screaming “I’m from a different neighborhood!”
and start whispering “I belong here.”

Why KDE/Qt Apps Look Weird on GNOME

GNOME apps are mostly built with GTK (and many modern ones use libadwaita), which controls how buttons,
switches, headers, spacing, and colors appear. KDE apps are mostly built with Qt, which has its own theming system,
its own plugins, and its own ideas about what a button should look like. Neither toolkit is “wrong”
they’re just speaking different visual languages.

When Qt doesn’t have a GNOME-aware theme/plugin to follow, it often falls back to a default style like
Fusion. Fusion is fine in the way plain toast is fine: technically edible, emotionally confusing.
That’s why your KDE apps can feel out of place on GNOMEdifferent fonts, different widget shapes,
mismatched icons, and dialogs that don’t look like they came from the same planet.

The Two-Part Fix: Adwaita-Qt + QGnomePlatform (Think “Makeup + Manners”)

1) Adwaita-Qt = the look

Adwaita-Qt is a Qt style plugin. In practical terms, it makes Qt widgets (buttons, checkboxes, sliders, etc.)
look more like GNOME’s Adwaita. It typically provides multiple variants like Adwaita and Adwaita-dark,
plus high-contrast options. So your Qt app stops looking like it fell out of a time machine.

2) QGnomePlatform = the integration

QGnomePlatform is a Qt platform theme plugin. That means it helps Qt apps follow GNOME preferences
(think fonts, icon theme, and certain integration behaviors). It’s the difference between a Qt app that merely
wears Adwaita clothing, and one that also knows how to behave at a GNOME dinner party.

Put together, this combo often gets you the “normal” look you want: GNOME-ish widgets, better font/icon consistency,
and fewer visual mismatches.

Step 1: Install the Right Packages

Package names vary by distribution, but you’re generally looking for:
adwaita-qt (Qt5/Qt6 style), qgnomeplatform (Qt platform theme),
and optionally QAdwaitaDecorations (for Wayland window decorations).

Fedora (and friends)

Try a search first (because package naming is a hobby for distros):

Then install what matches your Qt apps (Qt5, Qt6, or both):

Ubuntu / Debian-based

Names can differ by release, but commonly you’ll see packages along these lines:

If your distro provides Qt6 variants separately, install those too. If it doesn’t, that’s not you doing it wrong
it’s just packaging roulette.

Arch / Arch-based

If you’re on an Arch-based distro and something’s missing from official repos, it may exist in community repos or AUR.
Just remember: AUR is great, but it also occasionally doubles as “build-your-own-adventure.”

Step 2: Set Environment Variables the GNOME-Friendly Way

If you set variables in ~/.bashrc and nothing changes, that’s because GUI apps launched by GNOME typically
don’t read your interactive shell config. Instead, use systemd’s environment.d user configuration so it applies
consistently to graphical sessions.

Create an environment file

Create the directory (if it doesn’t exist):

Create a config file (name can be anything ending in .conf):

Add the following lines:

That’s the key setting that tells Qt to use the GNOME platform theme plugin (QGnomePlatform) when available.
Now log out and log back in. If it still doesn’t apply, do a full rebootsome setups are stubborn about inheriting
new session variables.

Optional: set a global style override

You can also set the Qt style globally via QT_STYLE_OVERRIDE. This is useful if your system isn’t automatically
picking Adwaita-Qt as the widget style.

If you prefer dark styling for Qt apps:

Note: if you use qt5ct/qt6ct for theming, it may complain or conflict with QT_STYLE_OVERRIDE.
In “pick one boss” terms: either let QGnomePlatform/Adwaita-Qt run the show, or let qt5ct/qt6ct run the show.
Mixing them can be… spicy.

Step 3: Force Adwaita-Qt Styling (When Qt Needs a Gentle Push)

There are three common ways to make sure Qt apps actually use the Adwaita-Qt style:
(1) environment variable, (2) per-app launch flag, or (3) app-specific settings.

Option A: Global (environment variable)

If you added QT_STYLE_OVERRIDE=adwaita (or adwaita-dark) to your environment.d file, you’re already doing this.
It’s the set-it-and-forget-it approach.

Option B: Per-app (the “just this one app, please” approach)

This is great when you want to test changes without committing your entire desktop to them.

Or using the Qt runtime style flag (works when the style plugin is installed):

Option C: Use a Qt config tool (situational)

Some desktops/tools can set a default Qt style via GUI configuration tools. That can work, but on GNOME it’s often
less reliable than environment.d because you want the setting to apply to apps launched from the shell, the dock,
search, and file associations.

Step 4: Wayland Window Decorations (Make Title Bars Stop Looking Like They’re From Another App)

Widgets are only half the battle. On Wayland, title bars and window decorations can be a separate messespecially when
a Qt app uses client-side decorations that don’t match GNOME’s header bars.

If you install QAdwaitaDecorations, you can tell Qt to use it for Wayland decorations via an environment variable:

On newer Qt6 setups, you may need to specify the plugin name explicitly (depending on how your Qt is packaged):

Then log out/in (or restart) and check whether the headerbar buttons and corner radii look more GNOME-native.
If you’re thinking “why is a corner radius so important?”congrats, you’ve become a desktop theming person now.
There is no turning back.

Troubleshooting: When Qt Pretends It Never Met GNOME

1) Verify your variables are actually set

If these come back blank in your GNOME terminal after logging in, your session isn’t inheriting them.
Make sure the file ends with .conf, lives in ~/.config/environment.d/, and you restarted the session properly.

2) Check the style names are real

If you see “invalid style override,” it usually means the style plugin isn’t installed or the style name doesn’t exist.
Remember: adwaita and adwaita-dark are common Adwaita-Qt style names, but your distro’s packaging can affect availability.
A quick test is launching one app with -style adwaita and seeing if it responds.

3) Remove (or pause) conflicting theming tools

If you’re using qt5ct/qt6ct, you might already have QT_QPA_PLATFORMTHEME=qt5ct set somewhere
(or set by a session component). That will override the “gnome” platform theme setting. Decide which approach you want:

• GNOME-native approach: QGnomePlatform + Adwaita-Qt (and maybe QAdwaitaDecorations)
• Qt-control-panel approach: qt5ct/qt6ct (plus a Qt theme of your choosing)

4) Fedora note: defaults can change

Some distros (notably Fedora Workstation in certain releases) have changed whether they ship or enable custom Qt theming by default.
If your Qt apps suddenly look more “Fusion-y” after an upgrade, it may be because the distro stopped applying the custom Qt theme automatically.
The fix is usually the same: install the components and set the environment variables yourself.

5) Flatpak apps: the sandbox can block your theme

If your KDE/Qt app is a Flatpak, it might not see your host’s Qt style plugins or config. You can try setting an override:

If it still doesn’t work, it may be because the Flatpak runtime doesn’t include the theme/plugin you’re trying to use.
In that case, you either accept the runtime’s available styles or switch installation method for that specific app.

Real-World Experiences: What It Actually Feels Like To Do This

The first time you try to “make KDE apps look normal on GNOME,” you’ll assume it’s going to be a single toggle.
(This is adorable. Never change.) In reality, it’s more like making a toddler wear matching socks: possible, but only after
patient negotiation and at least one moment where you stare at a config file and wonder how you got here.

My favorite part is the emotional roller coaster of “it worked!” followed immediately by “why didn’t it apply to this app?”
You’ll fix Okular and Krita, then launch Kdenlive and discover it’s still clinging to a different style like a cat to a curtain.
That’s usually when you learn the difference between platform theme and widget style the hard way:
fonts and icons might be correct (thanks, QGnomePlatform), but the widgets still look off until Adwaita-Qt is actually chosen.

Then there’s the “Wayland title bar saga.” You’ll get buttons and spacing looking GNOME-ish, but the window decorations still feel
a little… foreign. At first you’ll pretend it’s fine. Then you’ll notice the corner radius. And once you notice it, you can’t unsee it.
That’s when QAdwaitaDecorations becomes your “one last tweak, I swear” fix. You set QT_WAYLAND_DECORATION, reboot,
and suddenly the title bar stops looking like it was copied from a different operating system. It’s weirdly satisfying, like aligning
the corners of a picture frame.

The sneakiest lesson is where you set environment variables. If you put everything in ~/.bashrc, you’ll spend 30 minutes
convincing yourself GNOME is ignoring you out of spite. It’s not spiteit’s architecture. GNOME doesn’t launch your GUI apps through
your interactive shell, so your variables simply never show up where you expect. The first time you move them into
~/.config/environment.d/ and everything suddenly “sticks,” it feels like you discovered a secret passage in your own home.

The biggest practical win after all this? Consistency. KDE apps stop looking like a “special case” and start feeling like part of your workflow.
Your eyes relax. Screenshots look cleaner. Streaming or screen sharing looks more professional. And the tiny friction of “why does this dialog
look different?” fades away. It’s not just aestheticsit’s cognitive load. Once things match, your brain stops doing that little double-take.

The final (and most important) experience-based takeaway: keep it reversible. If an app glitches, don’t panic and don’t file a bug report
until you’ve tried disabling your overrides. Theming can trigger edge cases, and the fastest way to get help from maintainers is to reproduce
the issue with default settings. In other words: tweak boldly, troubleshoot responsibly, and always keep a “back to normal” switch.

SEO Tags (JSON)