I use a US English keyboard, but use my Compose key to type accented letters in Spanish and French. Within the past week, ibus has started to pop up a small window when I type Compose + ' to type a character with an acute accent, both in my GTK 3 Neovim frontend (neovim-gtk) and in MATE Terminal. This behavior did not previously occur and is not desired. It may be that this occurred earlier but did not take effect until I rebooted, which I do only infrequently. ibus has also changed other settings in unwanted ways in the past, such as changing certain hotkeys to Ctrl-Period, which I had mapped to other things. Could this change be reverted and all future changes to settings be made opt-in for the user?
Hi Brian,
Thanks for your report!
I don't see that on the GNOME desktop (Debian testing) at least.
1. What makes you think it's an IBus issue?
2. Can you please provide a screenshot, so we can see what it looks
like?
3. Do you see the small window if you define some other key as the
compose key than the one you currently use?
<snip>
You can pick some other emoji shortcut, and it looks like you already
did so.
Are you using Wayland? I'm using Xorg, so perhaps that's why we're seeing different behavior. Killing ibus-daemon stops it from happening. All the subsidiary processes exit when that happens as well, so it might be a different IBus process. To help troubleshooting, here's a listing of what's running from IBus when I see it: $ ps ax | grep ibus 1198762 ? Ssl 0:00 /usr/bin/ibus-daemon --daemonize --xim 1198776 ? Sl 0:00 /usr/libexec/ibus-dconf 1198778 ? Sl 0:00 /usr/libexec/ibus-ui-gtk3 1198781 ? Sl 0:01 /usr/libexec/ibus-extension-gtk3 1198787 ? Sl 0:00 /usr/libexec/ibus-x11 --kill-daemon 1198790 ? Sl 0:00 /usr/libexec/ibus-portal 1198876 ? Sl 0:00 /usr/libexec/ibus-engine-simple All of those are gone after I send a SIGTERM to ibus-daemon, and the problem disappears as well. Absolutely. I've attached one. It's very small, but distracting when I'm typing a long text in Spanish or French. What I've typed in the screenshot is Compose (that is, Windows) and the apostrophe. The key I use is the Windows key. Temporarily setting right Ctrl shows the same behavior.
Brian, Are you using ibus module for "English (int., with AltGr dead key)". Since I use GNOME/Wayland I can't be sure but all non-GNOME system configures ibus with "ibus-setup". There may be configuration option there. What was your intended system configuration. If it is a good old Pure-X way without ibus on non-GNOME, then you have to unload ibus. GNOME pull in this if you installed it previously. Osamu-----Original Message----- From: brian m. carlson <sandals@crustytoothpaste.net> Reply-To: brian m. carlson <sandals@crustytoothpaste.net>, 1004363@bugs.debian.org To: 1004363@bugs.debian.org Subject: Bug#1004363: ibus: pops up window with accent mark Date: Wed, 26 Jan 2022 01:53:30 +0000 Are you using Wayland? I'm using Xorg, so perhaps that's why we're seeing different behavior. Killing ibus-daemon stops it from happening. All the subsidiary processes exit when that happens as well, so it might be a different IBus process. To help troubleshooting, here's a listing of what's running from IBus when I see it: $ ps ax | grep ibus 1198762 ? Ssl 0:00 /usr/bin/ibus-daemon --daemonize --xim 1198776 ? Sl 0:00 /usr/libexec/ibus-dconf 1198778 ? Sl 0:00 /usr/libexec/ibus-ui-gtk3 1198781 ? Sl 0:01 /usr/libexec/ibus-extension-gtk3 1198787 ? Sl 0:00 /usr/libexec/ibus-x11 --kill-daemon 1198790 ? Sl 0:00 /usr/libexec/ibus-portal 1198876 ? Sl 0:00 /usr/libexec/ibus-engine-simple All of those are gone after I send a SIGTERM to ibus-daemon, and the problem disappears as well. Absolutely. I've attached one. It's very small, but distracting when I'm typing a long text in Spanish or French. What I've typed in the screenshot is Compose (that is, Windows) and the apostrophe. The key I use is the Windows key. Temporarily setting right Ctrl shows the same behavior.
@Brian: Thanks for additional info. I probably tested on Wayland. Now I have tested on Xorg too, and don't see it there either. I have one idea (and this is a long shot): Do you possibly have an ~/.XCompose file? If you have, can you try to rename it (in order to disable it), relogin, and try again. The reason I ask is that I have <https://launchpad.net/bugs/1849399> in mind. It shows that a mistake in ~/.XCompose might lead to unexpected behavior. @Osamu: Unloading ibus somehow would only be a workaround, right? I mean, you should be able to use a Compose key without issues also when the ibus-daemon is running.
The version I have has "English - English (US)". (Actually, my system is in French, so it says, "Anglais - Anglais (US)", but that's the translation). I definitely don't have dead keys enabled, nor do I have an AltGr key. Besides the standard Shift key, I have Fn (this is a laptop), Ctrl, Windows, and Alt. I have that installed and I don't see an option for this. I use MATE with Xorg and have never used GNOME or Wayland on this system. I do not need or want ibus, but I do use the video software Zoom, and it requires it to be installed (it's in Depends). I'm happy to switch to a different input method, but this bug remains valid even if I do so. ibus should refrain from popping up windows in this way or at least provide a way to configure it which defaults to off. Upgrading a system should not result in any changes to the way people input text because that's not expected nor wanted, and ibus has a history of doing exactly that.
I don't have an ~/.XCompose file. I use the standard X compose sequences. The only keyboard configuration I have at all is this in my ~/.Xsessionrc and an ~/.Xmodmap:---- setxkbmap -option capslock:escape -option compose:lwin \ -option terminate:ctrl_alt_bksp ---- The .Xmodmap looks like this:---- keycode 166 = Prior keycode 167 = Next ---- I don't believe those do anything anymore; I had an old laptop where those mapped keys to PgUp and PgDown, but the keys in those positions on this laptop are PgUp and PgDown. Otherwise, this is a totally standard, boring U.S. English configuration with a standard U.S. English keyboard. This did previously work just fine. I've had ibus installed for some time and I know it's been running because one of the key mappings changed unexpectedly, as I mentioned. I don't mind if it's installed as long as the behavior is as it used to be.
Control: tags -1 - moreinfo Oh no, not Zoom again. :( Saying that because zoom depending on ibus was the reason why the reporter of <https://bugs.debian.org/988540> run into problems. I think you can fix it for yourself by running this command: im-config -n none and reboot. That would prevent ibus from being started and configured at login. With that said, and as you rightly point out, this is still a valid bug. So let's keep it open and see if others run into the same issue and are able to shed some light on the root cause.
It is unclear to me as well why it's needed, but maybe that's because I don't speak a language for which it's necessary. All the languages I know happen to use the Latin alphabet. I picked xim here instead, since I think that's what I used to use and it seemed to work. Sounds good.
Since ibus can be taught to provide XKB functionality with proper configuration, loss of old way of setting input is wishlist bug request. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988540#116
im-config can be disabled to disable ibus running thanks