Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#1009996: IBus broken on GNOME on x11
234 views
Skip to first unread message
Gunnar Hjalmarsson
Apr 21, 2022, 10:20:04 PM4/21/22
to
Package: im-config
Version: 0.50-2
Hi!
The IBus configuration has been messed up somehow, and inputting using
IBus does no longer (Debian testing) work out of the box on GNOME on
Xorg. There is a problem also on Ubuntu 22.04 on Xorg, but there the
issue is limited to the candidate window being shown at the bottom of
the application window instead of close to the cursor.
Related Ubuntu bug: https://launchpad.net/bugs/1969637
There have been changes to gnome-settings-daemon in GNOME 42 which most
likely are related. The gtk-im-module dconf key is no longer assigned
the value "ibus" dynamically as was the case previously, but it's unset
even if IBus IMs are included in the list of input sources.
You can set gtk-im-module manually:
gsettings set org.gnome.desktop.interface gtk-im-module ibus
and IBus starts working. Another way to make it work is to set the
environment variable GTK_IM_MODULE to "ibus".
Please see the Ubuntu bug for further info.
Ideally we should of course try to spot the root cause of this issue and
fix it properly, and one purpose of submitting this bug is to seek help
in that respect.
But on the Ubuntu side this is really urgent. Ubuntu 22.04 LTS was
released yesterday, and there we should make a stable release update
ASAP with some kind of fix/workaround.
I submitted this im-config merge request:
https://salsa.debian.org/input-method-team/im-config/-/merge_requests/15
It works around the issue. Maybe we should use that on both Debian and
Ubuntu for now. In any case, unless some more proper solution comes up
very soon, I'm inclined to use it for a stable release update on Ubuntu.
--
Looking forward to your input!
Gunnar
Version: 0.50-2
Hi!
The IBus configuration has been messed up somehow, and inputting using
IBus does no longer (Debian testing) work out of the box on GNOME on
Xorg. There is a problem also on Ubuntu 22.04 on Xorg, but there the
issue is limited to the candidate window being shown at the bottom of
the application window instead of close to the cursor.
Related Ubuntu bug: https://launchpad.net/bugs/1969637
There have been changes to gnome-settings-daemon in GNOME 42 which most
likely are related. The gtk-im-module dconf key is no longer assigned
the value "ibus" dynamically as was the case previously, but it's unset
even if IBus IMs are included in the list of input sources.
You can set gtk-im-module manually:
gsettings set org.gnome.desktop.interface gtk-im-module ibus
and IBus starts working. Another way to make it work is to set the
environment variable GTK_IM_MODULE to "ibus".
Please see the Ubuntu bug for further info.
Ideally we should of course try to spot the root cause of this issue and
fix it properly, and one purpose of submitting this bug is to seek help
in that respect.
But on the Ubuntu side this is really urgent. Ubuntu 22.04 LTS was
released yesterday, and there we should make a stable release update
ASAP with some kind of fix/workaround.
I submitted this im-config merge request:
https://salsa.debian.org/input-method-team/im-config/-/merge_requests/15
It works around the issue. Maybe we should use that on both Debian and
Ubuntu for now. In any case, unless some more proper solution comes up
very soon, I'm inclined to use it for a stable release update on Ubuntu.
--
Looking forward to your input!
Gunnar
Osamu Aoki
Apr 22, 2022, 6:00:03 AM4/22/22
to
Hi Gunnar,
I don't use GNOME on x11 so you should know better than me. Please read the
following first and please give me your thought.
This part of logic in 21_ibus.rc all started around:
38989f8 ("Show IBus icon on Budgie desktop", 2020-08-04) -- you
8b13771 ("Refactor with new find_match and document", 2020-08-07) -- me
Logic around here is a part which can be easily tangled as I recall. I now know GTK
apps need `GTK_IM_MODULE=ibus` under GNOME on x11. That was different from what you
told me when we discussed to create this part of code.
> I submitted this im-config merge request:
>
> https://salsa.debian.org/input-method-team/im-config/-/merge_requests/15
>
> It works around the issue. Maybe we should use that on both Debian and
> Ubuntu for now. In any case, unless some more proper solution comes up
> very soon, I'm inclined to use it for a stable release update on Ubuntu.
I certainly agree that this patch seems to address stated issues for user of GNOME on
x11. But is this the best fix?
Let me first ask ask 2 key questions. Please help me:
Q1: Does desktop starts `ibus-daemon --daemonize --xim` for GNOME on x11 ?
Q2: Do we need to set `QT_IM_MODULE=ibus` under GNOME on x11?
Let me call your attention to the later part of 21_ibus.rc which sets following for
non-GNOME in PHASE 1
GTK_IM_MODULE=ibus
QT_IM_MODULE=ibus
CLUTTER_IM_MODULE=ibus
So adding only GTK_IM_MODULE in place you proposed and still not running ibus-daemon
and not setting other environment variables looked tangled way to address the issue.
If we are to exclude "hands off list" for GNOME on x11, why not just do so and leave
the rest of code shared. I mean if the answer to Q1 and Q2 are yes and yes, I think
it is cleaner to do the following patch:
```
$ git diff
diff --git a/data/21_ibus.rc b/data/21_ibus.rc
index 85cd3a2..45751b8 100644
--- a/data/21_ibus.rc
+++ b/data/21_ibus.rc
@@ -1,9 +1,10 @@
# start IBus
# vim: set sts=4 expandtab:
-# hands off to set up IM if listed in $DESKTOP_SETUP_IBUS
-if find_match "$IM_CONFIG_CURRENT_DESKTOP" "$DESKTOP_SETUP_IBUS" ; then
- # ibus set up is owned by desktop --> do the same as "none"
+# hands off to set up IM if listed in $DESKTOP_SETUP_IBUS and wayland
+if find_match "$IM_CONFIG_CURRENT_DESKTOP" "$DESKTOP_SETUP_IBUS" && \
+ ["$XDG_SESSION_TYPE" = 'wayland'] ; then
+ # ibus set up is owned by desktop on wayland --> do the same as "none"
return
fi
```
Extra discussion: Was the Budgie:GNOME issue related to this? (Were Budgie:GNOME
running under x11?)
FYI: I read Ubuntu bug: https://launchpad.net/bugs/1969637 but not so carefully. So
I may be missing something.
Regards,
Osamu
I don't use GNOME on x11 so you should know better than me. Please read the
following first and please give me your thought.
This part of logic in 21_ibus.rc all started around:
38989f8 ("Show IBus icon on Budgie desktop", 2020-08-04) -- you
8b13771 ("Refactor with new find_match and document", 2020-08-07) -- me
Logic around here is a part which can be easily tangled as I recall. I now know GTK
apps need `GTK_IM_MODULE=ibus` under GNOME on x11. That was different from what you
told me when we discussed to create this part of code.
> I submitted this im-config merge request:
>
> https://salsa.debian.org/input-method-team/im-config/-/merge_requests/15
>
> It works around the issue. Maybe we should use that on both Debian and
> Ubuntu for now. In any case, unless some more proper solution comes up
> very soon, I'm inclined to use it for a stable release update on Ubuntu.
x11. But is this the best fix?
Let me first ask ask 2 key questions. Please help me:
Q1: Does desktop starts `ibus-daemon --daemonize --xim` for GNOME on x11 ?
Q2: Do we need to set `QT_IM_MODULE=ibus` under GNOME on x11?
Let me call your attention to the later part of 21_ibus.rc which sets following for
non-GNOME in PHASE 1
GTK_IM_MODULE=ibus
QT_IM_MODULE=ibus
CLUTTER_IM_MODULE=ibus
So adding only GTK_IM_MODULE in place you proposed and still not running ibus-daemon
and not setting other environment variables looked tangled way to address the issue.
If we are to exclude "hands off list" for GNOME on x11, why not just do so and leave
the rest of code shared. I mean if the answer to Q1 and Q2 are yes and yes, I think
it is cleaner to do the following patch:
```
$ git diff
diff --git a/data/21_ibus.rc b/data/21_ibus.rc
index 85cd3a2..45751b8 100644
--- a/data/21_ibus.rc
+++ b/data/21_ibus.rc
@@ -1,9 +1,10 @@
# start IBus
# vim: set sts=4 expandtab:
-# hands off to set up IM if listed in $DESKTOP_SETUP_IBUS
-if find_match "$IM_CONFIG_CURRENT_DESKTOP" "$DESKTOP_SETUP_IBUS" ; then
- # ibus set up is owned by desktop --> do the same as "none"
+# hands off to set up IM if listed in $DESKTOP_SETUP_IBUS and wayland
+if find_match "$IM_CONFIG_CURRENT_DESKTOP" "$DESKTOP_SETUP_IBUS" && \
+ ["$XDG_SESSION_TYPE" = 'wayland'] ; then
+ # ibus set up is owned by desktop on wayland --> do the same as "none"
return
fi
```
Extra discussion: Was the Budgie:GNOME issue related to this? (Were Budgie:GNOME
running under x11?)
FYI: I read Ubuntu bug: https://launchpad.net/bugs/1969637 but not so carefully. So
I may be missing something.
Regards,
Osamu
Gunnar Hjalmarsson
Apr 22, 2022, 7:40:03 AM4/22/22
to
Thanks for your reply, Osamu!
On 2022-04-22 11:49, Osamu Aoki wrote:
> This part of logic in 21_ibus.rc all started around:
> 38989f8 ("Show IBus icon on Budgie desktop", 2020-08-04) -- you
> 8b13771 ("Refactor with new find_match and document", 2020-08-07) -- me
Yep, I remember.
> Logic around here is a part which can be easily tangled as I recall.
> I now know GTK apps need `GTK_IM_MODULE=ibus` under GNOME on x11.
> That was different from what you told me when we discussed to create
> this part of code.
GTK_IM_MODULE=ibus was not needed at the time, but the mechanism which
made it work was broken in GNOME 42. So it's a regression.
>> I submitted this im-config merge request:
>>
>> https://salsa.debian.org/input-method-team/im-config/-/merge_requests/15
>>
>> It works around the issue. Maybe we should use that on both Debian and
>> Ubuntu for now. In any case, unless some more proper solution comes
>> up very soon, I'm inclined to use it for a stable release update on
>> Ubuntu.
>
> I certainly agree that this patch seems to address stated issues for
> user of GNOME on x11. But is this the best fix?
It's a workaround, hopefully only temporary until we can do it properly
in the right package (maybe gnome-settings-daemon).
It's the urgency which motivates the workaround. Especially as regards
Ubuntu 22.04, which was released yesterday with the issue, but I suppose
we don't want a broken IBus on testing's GNOME on Xorg either.
> Let me first ask ask 2 key questions. Please help me:
>
> Q1: Does desktop starts `ibus-daemon --daemonize --xim` for GNOME on
> x11 ?
No. GNOME currently starts it like this:
/usr/bin/ibus-daemon --panel disable --xim
> Q2: Do we need to set `QT_IM_MODULE=ibus` under GNOME on x11?
No. That's already set by GNOME.
> Let me call your attention to the later part of 21_ibus.rc which sets
> following for non-GNOME in PHASE 1
>
> GTK_IM_MODULE=ibus
> QT_IM_MODULE=ibus
> CLUTTER_IM_MODULE=ibus
>
> So adding only GTK_IM_MODULE in place you proposed and still not
> running ibus-daemon and not setting other environment variables
> looked tangled way to address the issue.
Our original idea was to defer everything to GNOME. And GNOME still
starts ibus-daemon and sets XMODIFIERS and QT_IM_MODULE. So the only
thing we need to add through im-config is GTK_IM_MODULE.
> If we are to exclude "hands off list" for GNOME on x11, why not just
> do so and leave the rest of code shared. I mean if the answer to Q1
> and Q2 are yes and yes, I think it is cleaner to do the following
> patch:
But the answer to Q1 and Q2 are no and no. ;) And especially because of
the different way to start ibus-daemon (--panel disable) I think we
shouldn't go back to let im-config do things which are already done by
GNOME.
So for those reasons I think my merge request is better (even if it's a
workaround).
> Extra discussion: Was the Budgie:GNOME issue related to this? (Were
> Budgie:GNOME running under x11?)
Budgie is run under x11, and Budgie starts ibus-daemon and sets the same
variables as GNOME does. I don't know to which extent this new issue
affects Budgie. But OTOH, "GTK_IM_MODULE=ibus" won't hurt on x11.
> FYI: I read Ubuntu bug: https://launchpad.net/bugs/1969637 but not so
> carefully. So I may be missing something.
Ack. The issue is different in Ubuntu, but the proposed workaround
applies to Ubuntu too. The Ubuntu bug includes a couple of links to
interesting upstream gnome-settings-daemon commits.
--
Cheers,
Gunnar
On 2022-04-22 11:49, Osamu Aoki wrote:
> This part of logic in 21_ibus.rc all started around:
> 38989f8 ("Show IBus icon on Budgie desktop", 2020-08-04) -- you
> 8b13771 ("Refactor with new find_match and document", 2020-08-07) -- me
> Logic around here is a part which can be easily tangled as I recall.
> I now know GTK apps need `GTK_IM_MODULE=ibus` under GNOME on x11.
> That was different from what you told me when we discussed to create
> this part of code.
made it work was broken in GNOME 42. So it's a regression.
>> I submitted this im-config merge request:
>>
>> https://salsa.debian.org/input-method-team/im-config/-/merge_requests/15
>>
>> It works around the issue. Maybe we should use that on both Debian and
>> Ubuntu for now. In any case, unless some more proper solution comes
>> up very soon, I'm inclined to use it for a stable release update on
>> Ubuntu.
>
> I certainly agree that this patch seems to address stated issues for
> user of GNOME on x11. But is this the best fix?
in the right package (maybe gnome-settings-daemon).
It's the urgency which motivates the workaround. Especially as regards
Ubuntu 22.04, which was released yesterday with the issue, but I suppose
we don't want a broken IBus on testing's GNOME on Xorg either.
> Let me first ask ask 2 key questions. Please help me:
>
> Q1: Does desktop starts `ibus-daemon --daemonize --xim` for GNOME on
> x11 ?
/usr/bin/ibus-daemon --panel disable --xim
> Q2: Do we need to set `QT_IM_MODULE=ibus` under GNOME on x11?
> Let me call your attention to the later part of 21_ibus.rc which sets
> following for non-GNOME in PHASE 1
>
> GTK_IM_MODULE=ibus
> QT_IM_MODULE=ibus
> CLUTTER_IM_MODULE=ibus
>
> So adding only GTK_IM_MODULE in place you proposed and still not
> running ibus-daemon and not setting other environment variables
> looked tangled way to address the issue.
starts ibus-daemon and sets XMODIFIERS and QT_IM_MODULE. So the only
thing we need to add through im-config is GTK_IM_MODULE.
> If we are to exclude "hands off list" for GNOME on x11, why not just
> do so and leave the rest of code shared. I mean if the answer to Q1
> and Q2 are yes and yes, I think it is cleaner to do the following
> patch:
the different way to start ibus-daemon (--panel disable) I think we
shouldn't go back to let im-config do things which are already done by
GNOME.
So for those reasons I think my merge request is better (even if it's a
workaround).
> Extra discussion: Was the Budgie:GNOME issue related to this? (Were
> Budgie:GNOME running under x11?)
variables as GNOME does. I don't know to which extent this new issue
affects Budgie. But OTOH, "GTK_IM_MODULE=ibus" won't hurt on x11.
> FYI: I read Ubuntu bug: https://launchpad.net/bugs/1969637 but not so
> carefully. So I may be missing something.
applies to Ubuntu too. The Ubuntu bug includes a couple of links to
interesting upstream gnome-settings-daemon commits.
--
Cheers,
Gunnar
Osamu Aoki
Apr 22, 2022, 12:40:04 PM4/22/22
to
Hi,
Since no-no, I agree to go with what you proposed.
In order to avoid future confusion, can you add some of the key facts you stated.
> GTK_IM_MODULE=ibus was not needed at the time, but the mechanism which
> made it work was broken in GNOME 42. So it's a regression.
Please add specific commit reference as a comment by explaining the above statement..
> It's a workaround, hopefully only temporary until we can do it properly
> in the right package (maybe gnome-settings-daemon).
Let's add a comment to review situation by September/2022.
> It's the urgency which motivates the workaround. Especially as regards
> Ubuntu 22.04, which was released yesterday with the issue, but I suppose
> we don't want a broken IBus on testing's GNOME on Xorg either.
As I read the discussion, if this bug affects Debian/testing, and GTK_IM_MODULE=ibus
solves major concern which may come with on-screen keyboard, that's OK.
...
> Our original idea was to defer everything to GNOME. And GNOME still
> starts ibus-daemon and sets XMODIFIERS and QT_IM_MODULE. So the only
> thing we need to add through im-config is GTK_IM_MODULE.
I see. Let's add this stance as comment since this is a temporary work around.
> But the answer to Q1 and Q2 are no and no. ;)
I see.
> So for those reasons I think my merge request is better (even if it's a
> workaround).
As a code to fix issue, I agree with your merge request.
As for the issue tracking, I appreciate you add more context into comment.
> > Extra discussion: Was the Budgie:GNOME issue related to this? (Were
> > Budgie:GNOME running under x11?)
>
> Budgie is run under x11, and Budgie starts ibus-daemon and sets the same
> variables as GNOME does. I don't know to which extent this new issue
> affects Budgie. But OTOH, "GTK_IM_MODULE=ibus" won't hurt on x11.
I see.
> > FYI: I read Ubuntu bug: https://launchpad.net/bugs/1969637 but not so
> > carefully. So I may be missing something.
>
> Ack. The issue is different in Ubuntu, but the proposed workaround
> applies to Ubuntu too. The Ubuntu bug includes a couple of links to
> interesting upstream gnome-settings-daemon commits.
You are talking about Ikuya's message, I think. I didn't have time to check it yet.
Anyway, please upload updated im-config including your logic in the proposed patch.
Regards,
Osamu
Since no-no, I agree to go with what you proposed.
In order to avoid future confusion, can you add some of the key facts you stated.
> GTK_IM_MODULE=ibus was not needed at the time, but the mechanism which
> made it work was broken in GNOME 42. So it's a regression.
> It's a workaround, hopefully only temporary until we can do it properly
> in the right package (maybe gnome-settings-daemon).
> It's the urgency which motivates the workaround. Especially as regards
> Ubuntu 22.04, which was released yesterday with the issue, but I suppose
> we don't want a broken IBus on testing's GNOME on Xorg either.
solves major concern which may come with on-screen keyboard, that's OK.
...
> Our original idea was to defer everything to GNOME. And GNOME still
> starts ibus-daemon and sets XMODIFIERS and QT_IM_MODULE. So the only
> thing we need to add through im-config is GTK_IM_MODULE.
> But the answer to Q1 and Q2 are no and no. ;)
> So for those reasons I think my merge request is better (even if it's a
> workaround).
As for the issue tracking, I appreciate you add more context into comment.
> > Extra discussion: Was the Budgie:GNOME issue related to this? (Were
> > Budgie:GNOME running under x11?)
>
> Budgie is run under x11, and Budgie starts ibus-daemon and sets the same
> variables as GNOME does. I don't know to which extent this new issue
> affects Budgie. But OTOH, "GTK_IM_MODULE=ibus" won't hurt on x11.
> > FYI: I read Ubuntu bug: https://launchpad.net/bugs/1969637 but not so
> > carefully. So I may be missing something.
>
> Ack. The issue is different in Ubuntu, but the proposed workaround
> applies to Ubuntu too. The Ubuntu bug includes a couple of links to
> interesting upstream gnome-settings-daemon commits.
Anyway, please upload updated im-config including your logic in the proposed patch.
Regards,
Osamu
Gunnar Hjalmarsson
Apr 23, 2022, 4:10:04 PM4/23/22
to
Control: affects -1 gnome-settings-daemon
Hi Osamu,
On 2022-04-22 18:28, Osamu Aoki wrote:
> Since no-no, I agree to go with what you proposed.
Thanks for the green light.
I submitted an upstream gnome-settings-daemon issue:
https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/issues/682
I'm thinking that I should wait and see if I get any useful response
within a couple of days. If not, I'm going to apply and upload the
im-config patch for now. And yes, we should review the situation in a
few months.
> In order to avoid future confusion, can you add some of the key facts
> you stated.
Isn't a reference to this bug, and maybe also the g-s-d issue with a
more concise and complete problem description, sufficient?
> As I read the discussion, if this bug affects Debian/testing, and
> GTK_IM_MODULE=ibus solves major concern which may come with on-screen
> keyboard, that's OK.
Note that the OSK issue, which we discussed a lot a while ago, only
happens in wayland. It was never an x11 issue.
--
Gunnar
Hi Osamu,
On 2022-04-22 18:28, Osamu Aoki wrote:
> Since no-no, I agree to go with what you proposed.
I submitted an upstream gnome-settings-daemon issue:
https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/issues/682
I'm thinking that I should wait and see if I get any useful response
within a couple of days. If not, I'm going to apply and upload the
im-config patch for now. And yes, we should review the situation in a
few months.
> In order to avoid future confusion, can you add some of the key facts
> you stated.
more concise and complete problem description, sufficient?
> As I read the discussion, if this bug affects Debian/testing, and
> GTK_IM_MODULE=ibus solves major concern which may come with on-screen
> keyboard, that's OK.
happens in wayland. It was never an x11 issue.
--
Gunnar
0 new messages