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 ), 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
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 “[]”.
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.
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
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
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 Good luck
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…
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.
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.
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.