Fixing Generic Wayland Icons for Applications in KDE Plasma

If you run KDE Plasma on Wayland, you may have run into a small but persistent annoyance: some applications show up with a generic Wayland logo in the Alt-Tab switcher and the taskbar instead of their proper icon.

Why this happens

On Wayland, windows identify themselves to the compositor using an app_id. KWin tries to match this identifier against installed .desktop files to figure out which icon to display. The match is done against either:

• The .desktop file's base name (without the .desktop extension), or
• The StartupWMClass= field inside the file

If KWin can't find a match, you get the default Wayland logo as a fallback. This commonly happens when an application's .desktop file is named one thing (say, my-cool-app.desktop) but the binary reports a different app_id to the compositor (say, com.example.CoolApp). The two never meet, and you get a blank icon.

Step 1: Find out what your window actually reports

Focus the misbehaving window, then run this in a terminal:

qdbus org.kde.KWin /KWin queryWindowInfo

You'll get a block of output describing the currently active window. The important lines are desktopFile and resourceClass. For example:

desktopFile: jetbrains-idea
resourceClass: jetbrains-idea
resourceName: idea

The resourceClass value is what KWin uses to look up the icon. Note it down.

Step 2: Rename the .desktop file to match

Find the existing .desktop file for the application and rename it so its basename matches the resourceClass from step 1. Desktop files live in one of two places:

• ~/.local/share/applications/ for user-installed entries
• /usr/share/applications/ for system-wide entries

If the misbehaving file is system-wide, don't edit it in place — copy it to ~/.local/share/applications/ with the correct name instead. User-level files take precedence over system ones, so your renamed copy will win.

cp /usr/share/applications/wrong-name.desktop \
   ~/.local/share/applications/correct-name.desktop

Replace correct-name with whatever resourceClass you got from queryWindowInfo.

Step 3: Refresh the KDE cache

Plasma caches the desktop file database, so nudge it to pick up your new file:

kbuildsycoca6

Use kbuildsycoca5 if you're still on Plasma 5. Then restart the application and Alt-Tab away — the icon should now render correctly.

Fixing Weirdly Spaced Numbers in Red Panda Console on Firefox (Linux)

If you're using Red Panda Console in Firefox on Linux and the message value viewer looks like this — with characters spaced out in a strange, almost proportional way:

 

...you've hit a font fallback issue. Here's what's going on and how to fix it.

The cause

Red Panda's message viewer uses the Monaco Editor, which requests "Droid Sans Mono" as its primary monospace font.

When Firefox can't find the requested font, it falls back through its own chain and lands on Noto Sans Mono, which has known rendering quirks at small sizes on Linux — producing the spaced-out glyphs you see.

Chromium doesn't have this problem because it uses a different font matching strategy.

You can confirm the issue by opening DevTools → Inspector → Fonts tab on one of the affected elements. If it shows "Noto Sans Mono" as the rendered font, this fix applies to you.

The fix

We can use fontconfig to rewrite font requests on the fly — pointing both Droid Sans Mono and Noto Sans Mono requests at a font that renders cleanly, like JetBrains Mono.

First, make sure JetBrains Mono is installed:

sudo apt install fonts-jetbrains-mono

Then create ~/.config/fontconfig/fonts.conf:

<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>
  <match target="pattern">
    <test name="family">
      <string>Droid Sans Mono</string>
    </test>
    <edit name="family" mode="assign" binding="strong">
      <string>JetBrains Mono</string>
    </edit>
  </match>

  <match target="pattern">
    <test name="family">
      <string>Noto Sans Mono</string>
    </test>
    <edit name="family" mode="assign" binding="strong">
      <string>JetBrains Mono</string>
    </edit>
  </match>

  <alias>
    <family>monospace</family>
    <prefer>
      <family>JetBrains Mono</family>
      <family>Hack</family>
      <family>DejaVu Sans Mono</family>
    </prefer>
  </alias>
</fontconfig>

Rebuild the font cache:

fc-cache -fv

Verify the aliases are working:

fc-match "Droid Sans Mono"
fc-match "Noto Sans Mono"

Both should return JetBrainsMono-Regular.ttf.

Restart Firefox completely and reload Red Panda — the message viewer should now render with clean, properly-spaced monospace text.

Why <match binding="strong"> and not <alias>

An <alias> only applies when the requested font is missing. Since Noto Sans Mono is actually installed, an alias for it would be ignored. <match> with binding="strong" forces the substitution even when the requested font exists — which is exactly what we need to override Firefox's fallback choice.

Side effects to be aware of

This config rewrites every request for Noto Sans Mono system-wide to JetBrains Mono. For code and most UI use cases this is an upgrade, but if you rely on Noto Sans Mono's broader CJK coverage for specific apps, you may want to narrow the rule or drop the Noto Sans Mono match entirely.

How to rescue BTRFS partition with corrupted log

Fixing a Btrfs Mount Problem with btrfs rescue zero-log

If you’re using a Btrfs filesystem and it suddenly refuses to mount (often after an unexpected shutdown, power loss, or crash), one common cause is a corrupted log tree. A practical and relatively safe recovery step is to clear that log using:

Code:

sudo btrfs rescue zero-log /dev/<device>

If mounting fails: check dmesg

If the filesystem still refuses to mount after running btrfs rescue zero-log, the next step is to inspect the kernel messages. Btrfs usually logs detailed error information there, even when the mount command itself is vague.

Attempt the mount

sudo mount /dev/<device> /mnt

Inspect kernel messages with dmesg

Immediately after a failed mount attempt, run:

dmesg