How to disable GNOME's capturing of ctrl+shift+u?

I have to use Slack a lot for work (please, let’s not digress into endless “Slack sucks!” or “you should use XXX instead”, it’s not an option for me :wink: ), and it uses the ctrl+shift+u shortcut to format a web link. This is usually bound to triggering unicode input, but for a long time until a couple of days ago I was able to disable its use by GNOME by running ibus-setup and removing the binding on the Emoji > Unicode code point entry.

However, for some reason, this stopped working a couple of days ago. Now, when I type ctrl+shift+u on Slack or any other app (eg. gnome-text-editor), it shows an underlined ‘u’ instead.

Has anything changed officially or is this a side-effect of some other change? Do I need to change it somewhere else? I am using Fedora 42 workstation.

EDIT: for the record, the fix I was using has been working since 2022 until now

1 Like

Hi!

GNOME/GTK utilises gsettings/dconf for storing preferences. When in doubt (or curious what is using certain shorcut) you can use gsettings list-recursively | grep {what you want to search for}.

In this case, you can disable it with gsettings set org.freedesktop.ibus.panel.emoji unicode-hotkey “[]”.

I wonder why it stopped working for you tho

1 Like

Thanks for the tip @tragivictoria , but gsettings list-recursively only shows 4 results here:

❯ gsettings list-recursively
com.github.stunkymonkey.nautilus-open-any-terminal flatpak 'off'
com.github.stunkymonkey.nautilus-open-any-terminal keybindings '<Ctrl><Alt>t'
com.github.stunkymonkey.nautilus-open-any-terminal new-tab false
com.github.stunkymonkey.nautilus-open-any-terminal terminal 'gnome-terminal'

and org.freedesktop.ibus.panel.emoji unicode-hotkey is set to @as []

Pretty crazy, right?! :person_shrugging: This shouldn’t be a big deal, but I rely heavily on keyboard-shortcuts for text editing/formatting wherever I can.

That’s impossible, you’re on GNOME, right?

Huh, it also doesn’t work for me. I’m on Fedora Rawhide.

I use keyboard layout Other Typing booster to add emoji to apps

Yep, Fedora 42 with GNOME 48, running on Wayland. I was also expecting lots of entries with the list-recursively argument…

Just out of curiosity, what’s your output for gsettings list-recursively | wc -l ?

Thanks @ledeni , but entering emojis is not my main concern at the moment, I just want to understand how ctrl+shift+u is being intercepted globally before it reaches applications, and disable this behavior.

It’s 1545

You could set up a different value for the specific dconf key, e.g.:

gsettings set org.freedesktop.ibus.panel.emoji unicode-hotkey "['<Control><Alt><Shift>u']"
1 Like

:exploding_head: I knew something was wrong here. Even though list-recursively is supposed to list all keys if no schema is given, that’s not what’s happening here. If I run gsettings list-recursively org.freedesktop.ibus , it shows 47 key-value pairs.

I don’t want to dig deeper into the specifics of gsettings right now, so I just looped through all schemas with list-schemas and for each of them I ran gsettings list-recursively | grep -i shift. This gave me 70 results, but unfortunately there is no ctrl+shift+u :cry:

So, back to square 0…

One key aspect is that it is an universal keybinding, even the terminal outputs an underlined ‘u’ when I press ctrl+shift+u. So, it must be something done at a very high level – I would suspect gnome-shell, but it’s not listed there either.

Hi @tqcharm I tried just to make sure, and something interesting happened: the new keybinding also triggered the same behavior (showing an underlined ‘u’), but it did not prevent ctrl+u from doing the same thing. So, it is as if there were at least two configurations for the same feature (enter unicode chars), and we’re only affecting one :thinking:

1 Like

This sounds like a bug to me and I would make a bug report. As for why list-recursively doesnt work for you… I don’t know. We’re out of my depth :frowning: Good luck

1 Like

My guess is that something changed with the latest gnome-shell update released a couple of days ago. Also, I found this bug report on GTK from 2023 where the GTK devs explicitly state that ctrl+shift+u won’t be configurable on GNOME, so maybe I’ll have better chances trying to convince slack to use other keybinding for web links on Linux… :person_shrugging:

Interesting. I’m on GNOME (gnome-shell-48.6-1.fc42), and upon changing the keybinding, there is no underlined “u” in the text editor anymore. You might be hitting a corner case here with your setup.

Same version here, but I just can’t get rid of the underlined “u”. Pretty weird… there is something odd and subtle going on here on my setup.

Regardless, I must say the discussion I linked to on my previous post left me a little pessimistic about this.

I wouldn’t be. Since that conversation ended, a new key-value pair in dconf has landed. I assume there’s something with your setup that causes this behavior. As always, you can check if the issue is at user-level or not by creating a new user and trying to reproduce the issue.

That was a good suggestion. I just tried, and I have the same behavior with a fresh user, which means this is probably configured at system level.

What’s your result for env | grep -i ibus ? Here I have

❯ env | grep -i ibus
XMODIFIERS=@im=ibus
QT_IM_MODULE=ibus
$ env | grep -i ibus
QT_IM_MODULES=wayland;ibus
XMODIFIERS=@im=ibus
QT_IM_MODULE=ibus

FWIW, I’m on Silverblue, not Workstation, but I don’t think that should matter in this respect.

BTW, I just rebased to F43 an hour ago. I’m not sure if the first env variable in the output was there in F42, but I can check if needed. EDIT: The first env variable QT_IM_MODULES is only there on F43.

1 Like

Thanks for the info. Just confirming:

  1. Do you have slack installed? If so, are you able to insert links with ctrl+shift+u ?
  2. Does any other app (eg. gnome-text-editor) show de underline “u” when you press ctrl+shift+u ?

Sorry for asking so many questions, I’m really shooting blindly here hoping I hit something…

Run ibus-setup and disable “Unicode code point” on the “Emoji” tab.