I installed Fedora-Workstation-netinst-x86_64-24_Alpha-1.7.iso and added the KDE desktop with "dnf groupinstall kde-desktop-environment" after the installation. After starting the KDE desktop, I see the ibus icon in the KDE panel. ps aux | grep ibus-daemon confirms that ibus is running. But neither left click nor right click on the ibus icon in the KDE panel does anything. Therefore, I cannot switch between the ibus engines using the KDE panel and I cannot access the ibus setup. Left and right click on the other icons in the KDE panel opens some menus, i.e. this seems to work normal. The ibus icon in the KDE panel seems to be the only one where this does not work. Hovering with the mouse over the ibus icon in the KDE panel does pop up a tooltip showing "EN IBus Panel", clicking does nothing. I can still change the ibus engines manually on the command line using something like: ibus engine typing-booster:de_DE ibus engine xkb:us::eng and this works fine. But I think the icon in the KDE panel should do something as well.
I notice that issue but I work on another project for more than one month. It seems Plasma panel does not provide the right icon size at login and actually the very tiny icon is shown on Plasma panel. The workaround is to restart ibus-daemon. % ibus restart
“ibus restart” does not fix the problem for me, the ibus icon in the plasma panel is still not clickable. The icon size looks normal for me.
Created attachment 1150748 [details] ibus-icon-in-kde-panel-size-seems-normal.png The size of the ibus icon in the kde plasma panel looks normal.
(In reply to Mike FABIAN from comment #2) > “ibus restart” does not fix the problem for me, the ibus icon in > the plasma panel is still not clickable. > > The icon size looks normal for me. Sorry, seems you filed a different issue.
OK, the workaround is to exit ibus. % ibus exit % ibus-daemon --xim It seems ibus-ui-gtk runs GtkStatusIcon mode but not Indicator mode because imsettings-daemon does not get XDG_CURRENT_DESKTOP environment.
Do we have any ideas? Transferring to imsettings. I think checking $XDG_CURRENT_DESKTOP is the best way. ibus-daemon can get the variable if it's called from autostart directly.
I don't get the issue how XDG_CURRENT_DESKTOP affects? can you explain more?
ibus-ui-gtk3 switches GtkStatusIcon and Indicator modes by XDG_CURRENT_DESKTOP. ibus-ui-gtk3 shows Indicator in case XDG_CURRENT_DESKTOP=KDE and GtkStatusIcon otherwise. Seems now GtkStatusIcon also can be shown in Plasma notification area but GtkStatusIcon still has some problems likes this bug. And then Indicator still should be used in Plasma notification. Officially GtkStatusIcon is no longer supported in Plasma 5.
If ibus is being brought up by imsettings, it looks like imsettings works right. imsettings doesn't touch on the envvar of XDG_CURRENT_DESKTOP. if ibus can't see that, it should be another issue. it may be similar issue to bug#1326547, bug#1308856 and bug#1310063. for summary, the dbus session imsettings referring isn't an instance being brought up by /etc/X11/xinit/xinitrc.d/00-start-message-bus.sh in f24 anymore. this means all of the child processes like imsettings doesn't have inherited envvars from desktop-related processes. thus, processes relying on those variables ends up not working on f24. So basically it isn't a bug in imsettings IMHO however I could do similar thing to the fix of bug#1310063 for workaround if that helps. otherwise I don't think there are nothing I can do.
(In reply to Akira TAGOH from comment #9) > If ibus is being brought up by imsettings, it looks like imsettings works > right. imsettings doesn't touch on the envvar of XDG_CURRENT_DESKTOP. if > ibus can't see that, it should be another issue. it may be similar issue to > bug#1326547, bug#1308856 and bug#1310063. autostart applications can get XDG_CURRENT_DESKTOP but imsettings-daemon does not get it from imsettings-switch. It means ibus works if other IMF configuration tools are used. I'd think about imsettings-switch to send necessary environment variables to imsettings-dameon or run ibus-daemon from imsettings-switch? Probably I think this problem cannot be fixed in ibus side. > So basically it isn't a bug in imsettings IMHO however I could do similar > thing to the fix of bug#1310063 for workaround if that helps. otherwise I > don't think there are nothing I can do. IMSETTINGS_DESKTOP works with only imsettings. Can imsettings-switch send XDG_CURRENT_DESKTOP to imsettings-daemon?
(In reply to fujiwara from comment #10) > autostart applications can get XDG_CURRENT_DESKTOP but imsettings-daemon > does not get it from imsettings-switch. it does similar thing in the fix of bug#1310063. > I'd think about imsettings-switch to send necessary environment variables to > imsettings-dameon or run ibus-daemon from imsettings-switch? > > Probably I think this problem cannot be fixed in ibus side. I suppose ibus shouldn't depends on any envvars to have different behavior. it would be better to have an option to change the status icon's toolkit.
(In reply to Akira TAGOH from comment #11) > I suppose ibus shouldn't depends on any envvars to have different behavior. > it would be better to have an option to change the status icon's toolkit. We talked about that suggestion when I integrate indication in ibus. We need to detect the desktop automatically for users without exported options. Some users can run ibus-daemon without using IME configuration tools likes imsettings.
That's good. but ibus should relies on something else other than envvars. or at least should have a way to do so. just suggested a command line option because it is easy to implement. if there are any other idea, that would be even good. I don't think imsettings should takes care of envvars others is supposed to set. no exceptions. otherwise it needs to do similar thing each time forever a new one is coming up.
It seems you ask each IMF to have an option to switch GtkStatusIcon and Indicator if it checks environment variables. I think there would be some reasons not to inherit all environment variables through dbus but is it a good implementation that imsettings does not export necessary variables?
% env XDG_CURRENT_DESKTOP=KDE ibus-daemon would be better than % ibus-daemon --foo
(In reply to fujiwara from comment #14) > I think there would be some reasons not to inherit all environment variables > through dbus but is it a good implementation that imsettings does not export > necessary variables? Not exactly. until f23, dbus-launch had been established *after* the required envvars is set. on f24 and later, dbus has been moved to kdbus and systemd takes care of it. so this is obviously a regression. In fact, there seems similar issue related to envvars in gnome-keyring (https://bugzilla.gnome.org/show_bug.cgi?id=738205) and more. you can see some when googling it. For a solution/workaround, they seem tried to export envvars into dbus. I suppose XDG_CURRENT_DESKTOP should be one of them. you better bring this up to desktop developers to behave so if you like that way. I may need to investigate more to overhaul the architecture of imsettings to modernize perhaps. but it may takes more time and not on f24 timeframe.
(In reply to Akira TAGOH from comment #16) > In fact, there seems similar issue related to envvars in gnome-keyring > (https://bugzilla.gnome.org/show_bug.cgi?id=738205) and more. you can see > some when googling it. > > For a solution/workaround, they seem tried to export envvars into dbus. I > suppose XDG_CURRENT_DESKTOP should be one of them. you better bring this up > to desktop developers to behave so if you like that way. I'm not sure if it's the better approach. Since this problem does not happen if ibus-daemon is launched directly without imsettings, I'd think you could contact to them.
https://bug756324.bugzilla-attachments.gnome.org/attachment.cgi?id=312998 If which variables should be exported is different by desktop, I suggest to own the handling in imsettings. It might be better for you to discuss in freedesktop.
Fixed in imsettings-1.7.1-1.fc25. please test. if it works as expected, will push it for f24 updates.
Verified the fix. Since systemd & imsettings-daemon is not terminated by log-out, I had to reboot the system.
imsettings-1.7.1-1.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-2cf796f9c5
imsettings-1.7.1-1.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-2cf796f9c5
imsettings-1.7.1-1.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.
*** Bug 1350101 has been marked as a duplicate of this bug. ***