Unicode shortcut fails in GNOME "system" or "core" inputs

System Bare metal DISTRO_NAME = 'endeavouros' DISTRO_VER = 'notfound' VARIANT_ID = 'notfound' SESSION_TYPE = 'x11' DESKTOP_ENV = 'gnome' DE_MAJ_VER = '45'

Any DE(s) tried with Wayland?: using xORG

Keyboard type (IBM, Chromebook, Windows, Apple): Auto detected (it is an apple macbook pro 16.1)

List of devices seen by the keymapper (keyszer): 

keyszer v0.7.1
--------------------------------------------------------------------------------
Device               Name                                Phys
--------------------------------------------------------------------------------
/dev/input/event18   Keyszer (virtual) Keyboard          py-evdev-uinput
/dev/input/event17   Dynamic Function Row Virtual Input Device

/dev/input/event16   Apple Inc. Touch Bar Display Touchpad
                                                         usb-bce-vhci-6/input0
/dev/input/event15   Apple Inc. Apple Internal Keyboard / Trackpad
                                                         usb-bce-vhci-5/input1
/dev/input/event14   Apple Headset                       usb-bce-vhci-4/input0
/dev/input/event13   bcm5974                             usb-bce-vhci-5/input0
/dev/input/event12   HDA ATI HDMI HDMI/DP,pcm=11         ALSA
/dev/input/event11   HDA ATI HDMI HDMI/DP,pcm=10         ALSA
/dev/input/event10   HDA ATI HDMI HDMI/DP,pcm=9          ALSA
/dev/input/event9    HDA ATI HDMI HDMI/DP,pcm=8          ALSA
/dev/input/event8    HDA ATI HDMI HDMI/DP,pcm=7          ALSA
/dev/input/event7    HDA ATI HDMI HDMI/DP,pcm=3          ALSA
/dev/input/event6    Apple T2 Audio Codec Output         ALSA
/dev/input/event5    PC Speaker                          isa0061/input0
/dev/input/event4    Video Bus                           LNXVIDEO/video/input0
/dev/input/event3    Power Button                        LNXPWRBN/button/input0
/dev/input/event2    Sleep Button                        PNP0C0E/button/input0
/dev/input/event1    Power Button                        PNP0C0C/button/input0
/dev/input/event0    Lid Switch                          PNP0C0D/button/input0

Problem observed:
When using the alt+u (or any other combination what will generate a special character such as an ü) in any system (read: native, core) input then the conversion from the code to the actual umlaut fails. It's probably best to observe the video to see the issue. This happens only in native inputs such as the overview search, or the nautilus file browser search, etc.

Note, certain commands (such as cmd+backspace used to delete the whole content at once, also will not work in those inputs. It is as if Gnome somehow would revert partially to native keyboard in those inputs.

I have a high suspicion it to be caused by the :boom: one and only: adwaita and GTK4. Never seen anything work in any adwaita or GKT4 based app/UI in the way that I inteded it to, it is as if I am using some macOS on steroids when interacting with adwaita/gtk4: nothing can be customized and everything is "by design".

This is NOT an urgent issue at all if even an issue. I couldn't care less if I cannot input an ü in the search bar. But, thought you should know that - if my suspicion is right and it is due to adwaita/gtk4 - at some point we might need to think about forking gnome into a selfmaintained, non-adwaita version, if we want "our" stuff to keep working the way we want.

Screencast from 2023-12-17 17-22-32.webm

@smileBeda

Indeed there are a lot of strange problems with the overview search and other search/find fields in GNOME. I think at the heart of this is the "live" nature of the search, where it attempts to start searching as you type. This seems to interfere with the Unicode sequences, even if you disable Toshy's handling of this from the tray menu "OptSpec Layout" submenu (this can be done on-the-fly, no need to restart Toshy when changing anything in the tray icon menu), and try to do Ctrl+Shift+u (with physical Cmd+Shift+u, since Cmd becomes the RIGHT_CTRL key) and enter the Unicode address manually.

Note, certain commands (such as cmd+backspace used to delete the whole content at once, also will not work in those inputs.

That is due to an inability to identify being in a particular text area, all the keymapper can know is the app class (Nautilus) and the window title. But Cmd+Backspace should work while renaming a file or folder. At least it does here. I'm on Fedora 39, GNOME 45.1.

I've been able to fix a few of those issues in the Finder mods, sometimes by relying on the window title or a "portal" app class that pops up for the file dialogs in other apps. But there are limits to what can be done, even with keyszer, the fork of xkeysnail.

Here is something important. The GNOME code seems to have a special override of the "live" searching behavior that works better with the way the "Macintosh" keyboard layout variants work. If you have one of these variants selected (I actually do all the time, although I also keep the Toshy OptSpec layout active) then if you disable the OptSpec layout you can use the "native" method. You'll have to select your "Alternate Characters Key" in the GNOME Keyboard settings pane. I'm able to use my "Menu" key, which only exists on the right side of the Space bar on this PC laptop keyboard, to the right of the right-side Alt key.

Anyway, if you use this "native" way of getting the special characters from the "Macintosh" keyboard layout variant, the GNOME search fields seem to just sit there and let you finish the multi-key dead keys sequence when entering something like Ü.

It's a pretty aggravating problem, and I've been thinking about filing a bug report with GNOME about it.

On the plus side, I'm pretty sure if you just use the "base" character like "u" the search algorithm is supposed to pick up on all the accented Unicode variants since they get "folded" down into the base character for search purposes. But I could be wrong about that.

In short, I confirmed the issue, but I don't really have a good fix for it, other than to use the native keyboard layout special characters. It's weird that it works better, because I am pretty sure it also does the whole Unicode sequence in the background.

@smileBeda

Of course there are other twists to the tale, depending the keyboard you use. On an Apple keyboard you won't have the "Menu" key, which is not part of the Ctrl+Alt+Super modifiers that get moved around by the keymapper config. So to access the special characters while Toshy is running, even if the OptSpec layout is disabled, you will probably have to change the "Alt_Gr on Right Cmd" preference, so that the keymapper stops remapping the modifiers on the right side of the Space bar. This was an adaptation Kinto had for international keyboards.

So, if you set things up correctly between the Toshy preferences and the GNOME special characters key, you can have a sort of hybrid situation where Toshy will still provide the special characters using the left side Option/Alt key, while GNOME and the native "Macintosh" keyboard layout variant will do the special characters using the right side of the keyboard. This situation will only be rational with a US keyboard layout, since that is the only special character scheme I've implemented.

I have attempted in the past to use the keymapper to cause the left side of the keyboard to also have the special character key that GNOME would recognize, so the special characters would be available from both sides of the keyboard via the native method, but that didn't work. That special key seems to be recognized deeper in the input system, in a way the keymapper can't replicate by just changing the key code of another key to match it.

Some of the "Finder Mods" and wordwise shortcuts can probably still be fixed in the "portal" file pickers that just have a different app class than the native file manager. So feel free to report those, while using the Toshy diagnostic dialog (Shift+Option+Cmd+I,I) to determine the app class and window title. You have to quickly double-tap the "I" key in that shortcut.

But Cmd+Backspace should work while renaming a file or folder.

It does.

I think at the heart of this is the "live" nature of the search, where it attempts to start searching as you type

Right! That makes complete sense.

Thus, I had an idea, which already surfaced when I saw how the umlauts are composed: is it not possible to "compose" those "in memory" and then "print" the actual umlaut instead of letting the text area composing it? I am not capable at all in terms of Gnome coding, whatever it uses - but if I where to look at it from a Webdev standpoint which I am familiar with, I would let PHP compose the umlaut and then send that to the output, instead of letting the text area composing it. Of course that would still be an encoded character, but basically already sent as that to the text editor, rather than composing it on the fly in the editor. Not sure that makes sense, or if that is doable in Gnome, however it might be a way to resolve this?

Again, not anything that is somehow showstopping at all

All this possibly also explains why certain apps (for example, Epiphany web browser) simply will ignore any of the keyboard shortcuts in certain circumstances (for example when the bookmarks menu is open). Since you say you only know the app class and window title, it probably would need specific "compatibility layers" for each peculiar case and that might just not be possible in many cases.

Example: if you open epiphany then the app class and title are:

Appl. Class   = 'epiphany'
Wndw. Title = 'Home · Wiki · GNOME / Epiphany · GitLab'
Kbd. Device = 'Apple Inc. Apple Internal Keyboard / Trackpad'

But if you open the bookmarks menu, that does not change at all, and no shortcut will work anymore once that menu is opened. To address it, we probably would need the specific popup name or identifier, which is not available?

@smileBeda

is it not possible to "compose" those "in memory" and then "print" the actual umlaut instead of letting the text area composing it?

Nope. The keymapper on the Linux side basically operates as a virtual keyboard, looking at what you type and redirecting it to different keystrokes if there is a match to something in a modmap or keymap. The Unicode sequences work because they are just macros doing what you could do manually from the keyboard.

On the Windows side, Kinto uses AutoHotkey, which has access to far more information about the window and specific areas of the window, and can also "paste" strings and do many other things. Though I ran into a problem where it would paste the wrong characters if the encoding of the AHK file was wrong, so I implemented a very similar Unicode-based setup for the Windows version of the Kinto config.

The fork of the keymapper Toshy uses is already a huge improvement over the keymapper Kinto uses, having access to window titles and an added Unicode and string processor that really simplifies defining macros in the config file. But it's still just a keyboard. Quite literally.

In theory maybe some kind of copy/paste capability could be added, but that would really make the keymapper more complex with extraneous functionality, and would be completely out of my area of expertise.

if you open the bookmarks menu, that does not change at all, and no shortcut will work anymore once that menu is opened.

This is a general issue I've noticed with menus, at least in GTK environments and apps. I'm not sure it works quite the same in something like KDE Plasma. The menus of tray icons or the control center will even block Alt+Tab task switching until you make them go away. To be fair, they can be navigated with things like arrow keys, so they might have a good reason to intercept the keyboard input. But they don't have their own app class or window title info, as far as I know. So there's not much that can be done to keep them from interfering with some other shortcut.

If I use the diagnostic shortcut with something like the GNOME control center open, it just shows the focused app info for whatever is in the foreground under the menu. Like they are transparent, as far as the display server/compositor is concerned. 🤷🏽

If there is no context that can be used to identify something separately, that's the end of the story. I have found a number of things that can be fixed by using the window title, but this basically requires a full separate window with its own unique title, different from the main app window title. It hasn't been as useful as I had hoped originally.

RedBearAK / toshy

Unicode shortcut fails in GNOME "system" or "core" inputs #117