IBus Notifcation ibus-ui-gtk KDE Wayland error message
Can you give me a script or commands to fix this issue I see every-time I login to my KDE Debian 13 laptop? I'm seeing this pop up in the bottom left and then this other tiny window with a W icon pops up, as shown in the screenshot: IBus should be called from the desktop session in Wayland. For KDE, you can launch 'systemsettings5' utility and go to "Input Devices" -> "Virtual Keyboard" section and select "IBus Wayland" icon and click "Apply" button to configure IBus in Wayland. For other desktop sessions, you can copy the 'Exec=' line in org.freedesktop.IBus.Panel.Wayland.Gtk3.desktop file to a configuration file of the session. Please refer each document about the "Wayland input method" configuration. Before you configure the "Wayland input method", you should make sure that QT_IM_MODULE and GTK_IM_MODULE environment variables are unset in the desktop session.
(Thu 2025-12-18 08:10 ET) ChatGPT 5.2 said:
That popup happens when IBus is being started the “old way” (autostart / env vars) inside a KDE Wayland session. The clean fix is:
- Force those IM env vars to be unset for your Plasma session
- Disable any system autostart entries that launch ibus-daemon / ibus-ui-gtk3
- Log out / log back in
Run this once:
nano ~/scripts/fix-ibus-kde-wayland.sh && chmod +x ~/scripts/fix-ibus-kde-wayland.sh && ~/scripts/fix-ibus-kde-wayland.shPaste this into the file:
#!/usr/bin/env bashIf you actually need IBus (Japanese/Chinese/etc.)
This fix stops the annoying popup by preventing the “wrong” autostart path. If you still want IBus functionality, enable it the KDE Wayland-native way:
- System Settings → Input Devices → Virtual Keyboard → “IBus Wayland” → Apply
- Keep the env-vars unset (that part is correct for Wayland).
If anything weird happens, tell me what these show after your next login:
echo "SESSION=$XDG_SESSION_TYPE"You said:
I ran your script, logged out and back in (not restart) and the same problem is still happening adam@laptop:~$ uname -a Linux laptop 6.12.57+deb13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.57-1 (2025-11-05) x86_64 GNU/Linux adam@laptop:~$ systemctl --user show-environment | egrep 'QT_IM_MODULE|GTK_IM_MODULE|XMODIFIERS|SDL_IM_MODULE' || echo 'OK: none set' GTK_IM_MODULE=ibus QT_IM_MODULE=ibus XMODIFIERS=@im=ibus adam@laptop:~$
(Thu 2025-12-18 08:10 ET) ChatGPT said:
Yep — that output tells us exactly why my first script didn’t “stick”:
Your systemd user session environment is still being populated with GTK_IM_MODULE=ibus, QT_IM_MODULE=ibus, XMODIFIERS=@im=ibus before Plasma finishes starting. On Debian, that’s very commonly done by im-config (it sources ~/.xinputrc or /etc/X11/xinit/xinputrc at session start and exports those vars).
Fix (Debian way): set im-config to “none” (desktop default)
Run this:
nano ~/scripts/fix-ibus-kde-wayland-v2.sh && chmod +x ~/scripts/fix-ibus-kde-wayland-v2.sh && ~/scripts/fix-ibus-kde-wayland-v2.shPaste:
#!/usr/bin/env bashAfter you log out / back in, run:
systemctl --user show-environment | egrep 'GTK_IM_MODULE|QT_IM_MODULE|XMODIFIERS|SDL_IM_MODULE' || echo 'OK: none set'If it still shows =ibus after that, it means the system-wide im-config setting is forcing it via /etc/X11/xinit/xinputrc (Debian’s startup hook will fall back to the system file when no user file exists).
Then do this one-time system fix:
sudo im-config -n noneLog out / in again.
That should stop both the notification and the tiny ibus-ui-gtk3 “W” window.
If you do need IBus for non-Latin input: keep im-config on none (so it doesn’t set those env vars) and enable IBus Wayland from KDE’s Virtual Keyboard setting instead.
don't
i ran your v2 fix and after I logged in, I don't see the pop ups anymore. I did not run this because i have no problem >> sudo im-config -n none adam@laptop:~$ systemctl --user show-environment | egrep 'GTK_IM_MODULE|QT_IM_MODULE|XMODIFIERS|SDL_IM_MODULE' || echo 'OK: none set' OK: none set
(Thu 2025-12-18 08:10 ET) ChatGPT said:
Perfect — that’s the exact “win condition.”
- The popups are gone ✅
- Your user session environment has none of those vars set ✅ (
OK: none set)
And yep: if it’s fixed already, don’t run sudo im-config -n none. That command would only be needed if the system-wide config was still forcing ibus back on you.
If you ever want to sanity-check later, these are the two quick checks:
systemctl --user show-environment | egrep 'GTK_IM_MODULE|QT_IM_MODULE|XMODIFIERS|SDL_IM_MODULE' || echo 'OK: none set'If the issue ever returns after an update, it’ll almost always be because im-config (or a regenerated ~/.xinputrc) started exporting those variables again — and you can just re-run your v2 script.
You said: will anyone else running Debian 13 having this issue, be able to run your v2 script for a fix?
(Thu 2025-12-18 08:10 ET) ChatGPT said:
Yeah — anyone on Debian 13 (or 12/Testing) who’s on KDE Plasma Wayland and seeing that same IBus notification + the tiny ibus-ui-gtk3 window can usually run the v2 script and get the same result.
Why it works: on Debian, this problem is almost always caused by im-config (via ~/.xinputrc) exporting:
GTK_IM_MODULE=ibusQT_IM_MODULE=ibusXMODIFIERS=@im=ibus
…and that combination triggers IBus’s “don’t start me this way on Wayland” behavior. Your v2 fix basically forces the per-user input method to none and removes the user-level launcher variables, so the Wayland session stops spawning the wrong IBus panel.
When the v2 script is a good fit
✅ They use KDE Plasma Wayland
✅ They don’t specifically need IBus-as-the-global-IM-module variables set
✅ im-config exists (im-config -m works)
When they should not blindly run it
⚠️ They rely on IBus for Japanese/Chinese/Korean input and haven’t set up the Wayland-native method in KDE yet (System Settings → Input Devices → Virtual Keyboard → IBus Wayland).
⚠️ They’re on X11, where those env vars are often expected (it may still be fine, but it’s not the same problem).
⚠️ Their system-wide config is forcing ibus (rare, but then they may also need sudo im-config -n none).
Easy “revert” if someone needs IBus back
They can re-enable it with:
im-config -n ibus(log out / in after)
So: yes, it’s broadly usable for the exact Debian+KDE+Wayland symptom you showed — just with that one caveat: if someone truly needs IBus for typing, they should switch to the KDE Wayland method rather than the old env-var method.
You said:
Ok, thanks for the clarification. I have another question about and issue I have been having since day 1 with this laptop after switching to Debian 13, and I'm wondering if this ibus issue has been related. What the issue is. Sometimes, I experience strange copy paste behavior or what I copied, doesn't actually paste and often time I have to switch back to the other window and copy again. This happens when working with browsers, Kate text editor and the Konsole terminal
(Thu 2025-12-18 08:10 ET) ChatGPT said:
Good news: now that your IM vars are truly gone (OK: none set), this copy/paste weirdness is very likely a separate KDE Wayland clipboard/“ownership” thing, not IBus.
On Wayland, the app you copied from often serves the clipboard contents to the app you paste into. If the clipboard manager (Klipper) isn’t running, is hung, or the source app is weird (browser/XWayland), you can get exactly what you described: paste does nothing until you re-copy.
1) Quick reality checks
Run these right when it happens:
echo "SESSION=$XDG_SESSION_TYPE"If klipper isn’t running (or is wedged), that’s your smoking gun.
2) One-shot fix: restart Klipper (Plasma clipboard)
Try this immediately when it misbehaves:
kquitapp6 klipper 2>/dev/null || kquitapp5 klipper 2>/dev/null || true3) Make it a script you can run anytime
nano ~/scripts/restart-kde-clipboard.sh && chmod +x ~/scripts/restart-kde-clipboard.sh && ~/scripts/restart-kde-clipboard.sh4) Two common “gotchas” that feel like bugs
- Konsole selection ≠ clipboard copy
Highlighting text in Konsole sets the selection (middle-click paste behavior). For real clipboard copy across apps, use Ctrl+Shift+C in Konsole, then Ctrl+V elsewhere. - Mixing Wayland + XWayland apps can be flaky
Check in Firefox:about:support→ “Window Protocol” (Wayland vs X11).
If one browser is running under XWayland while Kate/Konsole are Wayland-native, clipboard bridging can occasionally act weird.
5) KDE setting that matters
Make sure Klipper is actually enabled:
System Settings → Workspace Behavior → Clipboard (or just search “Clipboard” in settings)
Enable history, and make sure it’s not disabled/removed from the tray.
If you tell me just one thing, I can narrow it to the exact root cause fast:
Run this right after a failed paste (before you “re-copy”):
pgrep -a klipper; systemctl --user status --no-pager plasma-kwin_wayland 2>/dev/null | sed -n '1,20p'(If you don’t want to paste status output, at least tell me whether klipper was running when it failed.)