Unable to unset Unicode code point shortcut (ctrl+shift+u) with GtkIMContextWayland

[simondrake]

Please fill in the following items if you don't know the root cause.

Which distribution and version?:

Ubuntu 22.04

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 22.04.2 LTS
Release:        22.04
Codename:       jammy

Which desktop environment and version?:

Gnome 42,5

$ echo $XDG_CURRENT_DESKTOP
ubuntu:GNOME

$ gnome-shell --version
GNOME Shell 42.5

Which session type?:

Wayland

$ echo $XDG_SESSION_TYPE
wayland

Which application and version?:

All applications

IBus version?:

$ ibus version
IBus 1.5.26

Issue description:

I'm unsure if this is an ibus issue or an Ubuntu one, but I cannot unset the Unicode code point shortcut (ctrl+shift+u).

What I've already tried:

• Deleting the shortcut from iBus preferences (ibus-setup)

• Changing the Keyboard input method system from iBus to XIM and none. I rebooted after each change, but ctrl+shift+u continued to give me the underscore u.

• Restarting/killing the iBus processes (pkill ibus)

• Deleting the shortcut with gsettings

$ gsettings get org.freedesktop.ibus.panel.emoji unicode-hotkey
@as []

$ dconf dump /desktop/ibus/
[general]
use-global-engine=true
use-system-keyboard-layout=false

[panel]
show-icon-on-systray=true
use-custom-font=false

[panel/emoji]
hotkey=@as []
unicode-hotkey=@as []

Weirdly, if I add a shortcut to ibus-preferences it works. For example, I add ctrl+shift+d and it acts the same way, but the ctrl+shift+u shortcut doesn't get removed, so it is clearly respecting ibus preferences in some way.

https://askubuntu.com/questions/1457596/unable-to-disable-ctrlshiftu-unicode-input-shortcut Is basically my issue, but there are no answers.

Steps to reproduce:

1. Use the ctrl+shift+u shortcut, and observe the underscore u.

Can you reproduce your problem when you restart ibus-daemon? (yes / no):

Yes. The same problem remains.

Do you see any errors when you run ibus-daemon with the verbose option?:

No.

Can you reproduce your problem with a new user account instead of the current your account? (yes / no):

I haven't tried creating a new account, as this doesn't seem to be user specific?

Updates

• The problem does not occur when running env GTK_IM_MODULE=ibus gedit

• These are my input sources:

$ gsettings get org.gnome.desktop.input-sources sources
[('xkb', 'us+mac')]

[fujiwarat]

IBus binds Ctrl-Shift-u to the Unicode typing in the ibus-extension-gtk3 component by default but the shortcut key can be customized with ibus-setup utility.

In case of using GTK_IM_MODULE=wayland, GtkIMContextWayland is activated and the parent class is GtkIMContextSimple which binds the hard-coded Ctrl-Shift-u to the Unicode typing. If ibus-extension-gtk3 does not handle Ctrl-Shift-u, the key is forwarded to GtkIMContextWayland and GtkIMContextWayland sends the key to the parent GtkIMContextSimple .

static gboolean
gtk_im_context_wayland_filter_keypress (GtkIMContext *context,
                                        GdkEvent     *key)
{
  /* This is done by the compositor */
  return GTK_IM_CONTEXT_CLASS (gtk_im_context_wayland_parent_class)->filter_keypress (context, key);
}

So it's a GTK issue and cannot be resolved in IBus.

Which application and version?:
All applications

I think the effected applications are GTK only.

In case of using GTK_IM_MODULE=ibus, IBusIMContext is activated and If ibus-extension-gtk3 does not handle Ctrl-Shift-u, the key is forwarded to IBusIMContext but IBusIMContext does not handle Ctrl-Shift-u and your issue does not happen.

I think you could report your issue to GTK instead so that GTK customize the shortcut key likes IBus.

[simondrake]

Thanks @fujiwarat, good to know what the actual issue is (that I'm using Wayland).

Is there a way to force the use of iBus? I tried setting the below in /etc/profile, just to see if it would make a difference, but it didn't

export GTK_IM_MODULE="ibus"
export QT_IM_MODULE="ibus"
export XMODIFIERS="@im=ibus"

[gunnarhj]

@simondrake: Since you use Wayland, you should not set GTK_IM_MODULE explicitly, but let GNOME handle it internally. Otherwise you cause some adverse side effects.

As regards the other two variables, setting them explicitly is meaningless since they are already set by GNOME. If you drop that stuff from /etc/profile and relogin you can see for yourself by running this command:

env | grep -E 'XMOD|_IM'

[simondrake]

@gunnarhj got it, thanks. So this is just something I need to live with until it's handled in GTK?

I'll see if I can find the appropriate place to report it to GTK.

[fujiwarat]

If you could inform the GTK issue # here, it would be great.

[gunnarhj]

@simondrake wrote:

So this is just something I need to live with until it's handled in GTK?

You can log in to Ubuntu on Xorg in the meantime.

@fujiwarat: I just reported https://gitlab.gnome.org/GNOME/gtk/-/issues/5865 .

[fujiwarat]

@simondrake Why do you wish to disable Ctrl-Shift-u in the input method?

[fujiwarat]

@gunnarhj Thank you.

[simondrake]

@fujiwarat: I just reported https://gitlab.gnome.org/GNOME/gtk/-/issues/5865 .

I'm assuming based on the response that it's by design and they aren't going to support it, but I'll follow it just in case.

@simondrake Why do you wish to disable Ctrl-Shift-u in the input method?

@fujiwarat - I don't use it and it's a keyboard shortcut I use in other apps (e.g. Link in Slack). If I can't unset it, I can't use those keyboard shortcuts.

[mezpahlan]

@simondrake Why do you wish to disable Ctrl-Shift-u in the input method?

I can't speak for Simon but for me it is because it conflicts with other application shortcuts that I use in my workflow.

[gunnarhj]

I just reported https://gitlab.gnome.org/GNOME/gtk/-/issues/5865 .

I'm assuming based on the response that it's by design and they aren't going to support it, but I'll follow it just in case.

That's not my interpretation (in that case he would have closed it). I rather take his short reply as a confirmation that it's a valid issue. OTOH we don't know how long it takes before someone starts working on it...

[simondrake]

That's not my interpretation (in that case he would have closed it). I rather take his short reply as a confirmation that it's a valid issue. OTOH we don't know how long it takes before someone starts working on it...

Entirely possible I didn't interpret it correctly. Hopefully they pick it up at some point. Thanks for raising it.

[fujiwarat]

@simondrake Sure.

@mezpahlan If you know other apps, please let me know them. I think we need to inform your usages to GTK upstream.

[mezpahlan]

Slack was my example app too.

(In the browser if that matters?)

[simondrake]

I think I remember seeing an issue with this shortcut and a Jetbrains IDE, but I don't use them so I can't confirm if that's still the case or if it can be configured differently.

(In the browser if that matters?)

It doesn't. It's the same in browser and in desktop app.

[simondrake]

Here's the issue I remembered seeing - https://youtrack.jetbrains.com/issue/IDEA-112533/Toggle-Case-Ctrl-Shift-U-not-working-under-Gnome-Linux

[fujiwarat]

Probably I think the suggestion is to ask Slack to have the customization of the shortcut keys.
I can make a warning dialog in ibus-setup if the key customization dialog is open in GNOME Wayland.

Otherwise you could comment on the GTK issue.

[simondrake]

I don't want that key to be customizable
It has been Ctrl-Shift-u since before slack existed...

Sounds like it's not going to get resolved in GTK so it's a matter of live with it, or get Slack to allow the customisation.

Thanks for all the help looking into this @fujiwarat, it's very much appreciated.