Open Kuuhhl opened 1 year ago
Does this happen in every application? If not, might it be related to #285 ?
Yes, it happens in every application.
@Kuuhhl What version are you running (keyd -v
)? What is your DE?
I am now using keyd v2.4.3 (d2aa2f7)
with Hyprland as the compositor.
Umlauts are working in some Apps (for example Kitty Terminal, VSCode in XWayland-Mode) but don't work in others (like Firefox, VSCode in Wayland-Mode).
In the Apps where it doesn't work, the Umlauts turn into Codes, for example
ä
turns into 02s
ö
turns into 03a
Unfortunately you are running into a chromium(/electron) bug on wayland, which causes it to ignore the XCompose file. It may be possible to fix this by using ibus or fiddling with your chromium flags to force it to use GTK 4/X.
[1] https://bugs.chromium.org/p/chromium/issues/detail?id=506838 [2] #273
I've got a near identical issue except that all GUI windows in Gnome show the codes - like file manager, system settings, etc. However foot
, alacritty
, xfce4-terminal
and terminator
displays the correct utf8 chars - but terminology
and Gnome's terminal doesn't.
I assume this is a Gnome/GTK issue (and EFL in the case of terminology
) but can't figure out what/where - I've enabled compose:menu
in Gnome's keyboard config, .XCompose is linked...
Flatpak apps have the same issue as well as running from a chroot.
Any clues appreciated!
keyd --version
keyd v2.4.3 ()
gnome-shell-45.0-r0
I played little bit on that subject.
I'm using now: xkb variant altgr-intl The ~/.Xcompose and option compose:menu is not required for that setup. Compose is not used, but it works only with available keys in that layout variant, which should work for most European layouts?! (But it's not like sending any unicode char) Symbols can be created by: a) sending a macro with the dead key and the key b) sending the key combination directly, that is mapped in the us(altgr-intl) Symbol details are in the intl (altgr-intl) layouts: /usr/share/X11/xkb/symbols/us
So the sample should work like Kuuhhl wants to have it and explain the details for other setups:
# us with variant altgr-intl for symbols check:
# /usr/share/X11/xkb/symbols/us -> intl (altgr-intl)
# altgr-intl it is almost the same as intl, but the dead_ keys are out of the way
# choosing that variant adds a lot of extra keys in combination with altgr
[ids]
*
[main]
capslock = layer(caps)
; = :
[shift]
; = ;
# caps layer will send altgr combinations and X11/wayland
# will create the symbols from the variant layout
[caps]
s = G-s
# works as macro with dead_diaeresis
a = macro(G-" a)
# a = macro(G-S-apostrophe S-a)
# or directly mapping to the key
# a = G-q
u = G-y
o = G-p
# €
e = G-5
; = ;
[caps+shift]
# if using macro, it needs to be created for shift too
a = macro(G-" S-a)
# u/o works automatically, because the shift modifier is applied to the G-y/G-p, which is the shifted version
# ¢
e = G-S-c
# optional - remove dead_... keys
# just as sample, there are more:
# /usr/share/X11/xkb/symbols/us -> altgr-intl
[altgr]
# will remove from altgr and altgr+shift
grave = noop
[altgr+shift]
# keep dead_acute, but remove dead_diaresis
apostrophe = noop
PS: Not sure, if combining of unicode characters could be a more general approach, but no idea, how to do it. I couldn't even create the symbols in my terminal in wayland... ( https://en.wikipedia.org/wiki/Combining_character )
I've got a near identical issue except that all GUI windows in Gnome show the codes [...] I assume this is a Gnome/GTK issue
Yes, this is likely related to #273.
Flatpak apps have the same issue as well as running from a chroot.
I'm not familiar with flatpak, but if the apps are sandboxed (or running inside a chroot), they presumably won't have access to your ~/.XCompose
file, which is necessary in order for the the (supporting) applications to properly interpret the generated keyd sequences.
Compose is not used, but it works only with available keys in that layout variant, which should work for most European layouts?! (But it's not like sending any unicode char) [...] Symbols can be created by: a) sending a macro with the dead key and the key
Indeed, this is similar to how unicode support works under the hood. keyd ships a giant XCompose file containing most desirable symbols and then generates the necessary sequences to produce the character. Unfortunately XCompose support is application specific and broken in many modern toolkits (e.g GTK4), with some applications (especially on wayland) not supporting it at all.
The alternative, as you've just graciously documented, is to set your XKB layout to a specific language and the manually generate whatever sequences that layout associates with the symbol using keyd. I've been meaning to document these limitations better and find some time to experiment with alternative input methods.
thanks @rvaiya, that explains why everything but the terminal is broken in my Gnome env. I'll double check of my .XCompose is accessible from the chroot :+1:
Two other options to consider:
First option is find the unicode. What I do to create ù symbols is
macro(C-S-u f9 space)
The space at the end is optional.
Second option is find a key on a keyboard that creates the dead_diaeresis that you want. In my English international with dead keys that is Altgr-Shift-', so:
[ = G-S-'
I am trying to convert this
.Xmodmap
configuration to keyd:This is what I tried doing in the keyd configuration, based on what I read in the manpage about Unicode Support:
I also symlinked
/usr/share/keyd/keyd.compose
to~/.XCompose
.What happens when pressing one of the keys, however, is that a 5-digit number appears instead of the unicode character. Setting
setxkbmap -option compose:menu
makes no difference. What am I doing wrong?