I recently upgraded two machines to Tumbleweed from Leap 42.2 (both KDE) and on both iBus panel went missing. Ibus daemon itself works, ibus-setup works, language switch can be configured and also works, but there’s no switching icon in systray, which confuses everyone else who uses these computers.
Issues with missing iBus panel have been brought up several years ago in various places, including this forum, and from that I gathered that it’s the “ibus-ui-gtk3” that shows it. For some people manually specifying it when starting iBus worked but otherwise people are advised to use “kimpanel-ibus-panel” instead. Some users were told to uninstall kimpanel, though.
In any case, starting ibus with ibus-ui-gtk3 doesn’t show it in my systray (no errors reported in terminal either) and I don’t think I have kimpanel at all. Arch Wiki say this on iBus:
IBus main interface is currently only available in GTK+, but Kimpanel provides a native Qt/KDE input interface. Kimpanel is bundled with Plasma 5, but IBus needs to be launched as following to be able to communicate with the panel
I don’t have this package in either /usr/lib/ or /usr/lib64/ or anywhere else. “Software management” doesn’t show any results either. I don’t know if I had it on Leap, maybe it got lost with upgrade to newer Plasma.
Plasma comes with its own kimpanel “addon” (that should support ibus too) included, there is no separate package anymore.
Maybe it’s disabled on your system for some reason…
Right-click on some empty space in the system tray (preferably the up-arrow that shows hidden entries), choose “System Tray Settings” and see if you can activate it there.
Or, you can also add it somewhere else on the panel or the desktop by using “Add Widget…”.
The ibus daemon should be started automatically on login if installed though.
Ah, that’s it - but not on the desktop, it’s “Add Widget” in “Panel settings” and it’s called “Input methods panel”. When it’s added to the panel itself it shows an icon with ibus options.
Somehow when I tried it first it gave me an empty panel with the ability to add languages and did not show running ibus options. When I added languages to that new panel it interfered with ibus selections and the result was horrible. I got similar effects when adding keyboard layouts from KDE Settings panel and gave up on it.
Now, however, adding that widget to desktop works the same as adding it to the panel (it’s not in System Tray per se) and this new working ibus switch sits on the desktop, which isn’t what I want or what people expect.
That was just informational. You can add it to the desktop if you want, I didn’t say you should do that.
But again, the default place is the system tray (not the panel), and actually it should be there by default (unless you explicitly disabled it in the past, again see he “System Tray Settings”).
As it is the very same widget, it should also work the same, regardless where you place it.
It is still not in System Tray but sits as a separate widget in the panel. Clipboard, for example, can be added as a widget and it can be enabled from System Tray settings as well, but not ibus or any other input selection method. At least not for me.
Sure.
If you add it to the panel, it will be in the panel, not in the System Tray.
Clipboard, for example, can be added as a widget and it can be enabled from System Tray settings as well, but not ibus or any other input selection method. At least not for me.
It’s called “Input methods panel” as you wrote, not “ibus” or “any other input selection method”…
But indeed, it’s “missing” here too.
I thought it should be there.
I know that people complained about it automatically appearing when libreoffice-kde4 was dropped in Tumbleweed (libreoffice-gnome was installed instead then, which also pulled in ibus).
Maybe a bug that should be reported at bugs.kde.org…
I don’t use ibus myself (I have even tabooed it to not getting it installed), nor any other input methods.
After one of the recent updates ibus/input method panel got broken again - it’s just blank space on the panel, right-click on it gives “settings” option which presents a standard KDE window with no actual options besides “vertical list” and “default font” radio buttons. Adding this widget to desktop also creates a blank square with nothing in it and the same right click behavior.
Ibus itself keeps working, keyboard shortcuts switch languages and a switching window shows up in the middle of the screen.
I use TW with KDE but also have Gnome installed. I removed ibus completely because it screwed up KDE for me, everything was fine in Gnome but not KDE, in KDE it defaulted to English US but offered no English UK - QWERTY
As far as I can tell, it’s removal has had no negative impact
I use custom keyboard layouts for diacritic scripts under m17n, afaik they only work with ibus. Maybe I’m wrong but I haven’t touched that custom table for years, can it be activated under any other input switch?
I see that for m17n inputs there’s “ibus” but also “fcitx” and “scim”. How to manage these things? Can they co-exist side-by-side or will they produce conflicts? Should I install just one and remove all the others, try all three this way and then see which one works?
I tried with fcitx but couldn’t get anywhere and nothing switched, maybe I did it wrong. Ibus panel came back with one of the latest updates and so far stays in the tray/next to tray in the panel, so it’s all good for now but who knows for how long. Do fcitx and scim get a more stable KDE integration?
fcitx seems to receive a lot more attention (development / integration) in openSUSE (especially plasma) than ibus does these days.
I switched to using fcitx for Japanese input a few years ago and avoid the headaches that seem to plague ibus on every openSUSE release.
How to transition to fcitx smoothly, without getting old ibus and new fcitx into conflicts.
I mean what happens if I kill ibus daemon? Which input method control takes over? Right now my konsole doesn’t take any keyboard input if I do that, but I can open a new konsole window with a shortcut from KDE settings and start typing there.
I tried installing and using fcitx yesterday, got three entries into KDE menu, but only one of them worked, and then it showed a greyed out window with big red cross saying that something is blocking it. Then I managed to have it open up properly and configure my inputs, but it didn’t react to switching keyboard shortcuts. There’s fcitx-ui or similar sounding package but clicking on it in the menu gave me nothing, even when I enabled it in “fcitx settings”, I tried to set default layout in settings, too, but it didn’t stick. So I uninstalled it until I figure out how it all works.
Oh, and after deleting it I saw that fcitx added an icon to panel, but it was just a blank space and reacted only to clicking on it, which I found accidentally. The popup panel didn’t look like a native KDE thing but similar to ibus GTK panel.
I hope all this is explained somewhere in manuals, but what if all these problems are due to input method conflicts? Which manual would cover that?
you’ll also need whatever addon for your specific language input.
for me to get Japanese input I use mozc
mozc
mozc-gui-tools
fcitx-mozc
you’ll need to log out and back in once installed - then launch fcitx to get the keyboard in your tray. Then right click the keyboard and select *configure
*From there you can set up your languages / input methods and the keyboard triggers to switch between them.
In the configure window you’ll probably need to uncheck “only show current language” to find the language you’re looking to add.
These schemas have nothing to do with KDE, but rather GNOME/GTK (that message actually comes from GLib/GIO as you should be able to see…).
This particular one is included in the ibus package itself. (/usr/share/glib-2.0/schemas/org.freedesktop.ibus.gschema.xml, which also contains the definition of the ‘org.freedesktop.ibus.general.panel’ schema that the error message complains about)
No idea why that error would be shown (assuming that ibus itself is installed), or whether it’s relevant to your problem.
