Voidrice: Mod+7 and Mod+Shift+7 has unexpected behavior

[LJNielsenDk]

Mod+7 opens a terminal and Mod+Shift+7 closes the active window instead switching to or moving the current window to 7th virtual desktop respectively as I'd expect it to given how all the other numbers behave with the Mod key.

Is this intentional? If so then I'd like to know why and suggest adding a note about it somewhere in the Mod+F1 document too.

[richard134]

Hi,
For me this shortcut works fine. I think the problem you are facing is because you use a Danish keymap.
Try to change keymap to US to see if that solves the problem. There is a way to group the key bindings in i3 depending on your keymap or use keycodes, you can read about it here i3 manual

[LJNielsenDk]

@richard134 Huh, turns out it works for me with the US layout too.

I set my layout with setxkbmap -layout dk,us but if I switch it around so it's us,dk it works as expected.

I'm not sure I understand the part about groups at the bottom of section 4.3 in your link.
Assuming setxkbmap -layout dk,us when I press the key the keycode is translated to the keysym that it corresponds to in the dk layout?
If so, how come it doesn't match with the keysym-based binding?
If not, how does it work and what do they mean by it being translated in Group1 by default?

[richard134]

@LJNielsenDk When they say,

By default, keybindings are translated in Group1 and are active in all groups.

They mean that if you for example have us as first layout the keybindings will be translated from us to second or third layout. If you would like a different command to be run for a specific binding in the other layouts you can for example use,

bindsym Group1+$mod+v split v
bindsym Group2+$mod+v split v

But as Group1 should translated you should not have to do this.

For example I currently use:
setxkbmap us,se -option "caps:super,grp:switch,grp:alt_shift_toggle,grp:lalt_lshift_toggle,shift:both_capslock_cancel"

From my experiments it also worked good with:
setxkbmap us,dk -option "caps:super,grp:switch,grp:alt_shift_toggle,grp:lalt_lshift_toggle,shift:both_capslock_cancel"

The options added is

# default LARBS
caps:super               Make Caps Lock an additional Super
# Swap layout group
grp:switch                  Right Alt (while pressed)
grp:alt_shift_toggle        Alt+Shift
grp:lalt_lshift_toggle      Left Alt+Left Shift
# Turn caps on
shift:both_capslock_cancel   Both Shift together enable Caps Lock; one Shift key disables it

See man xkeyboard-config

I would suggest to add this to .scripts/tools/remaps

[stormsz]

i just would like to point out that, this solution doesn't work for everyone.
setxkbmap us,pt doesn't work. i tried a bunch of other stuff to get it to working but in the end i just manually did the keybinds switch from US to PT
anyway, just food for thought since i'm sure other people saw this solution and couldn't get it to work.

edit: before someone asks, yes i did the man xkeyboard-config for the correct variant of my keyboard.

[dr3mro]

I use Finnish Keyboard and I had same issue was able to fix it by commenting those 2 lines from i3 config file

bindsym $mod+apostrophe split horizontal ;; exec $term

bindsym $mod+slash split vertical ;; exec $term

[stormsz]

Ok guys, i think i found an "universal" solution, but that would need Luke to change how he binds the keys on is i3/conf file.

so as we know there's the problem with the meta+slash bind (and others) since, in my case the slash is located on the 7 button, so when i press meta+7, it opens an terminal instead of the workspace switch.

the solution that i found:
bindsym binds to the symbols, sobindsym $mod+a binds to the letter a
BUT!
bindcodebinds to the physical KEY also the bindcode doesn't uses symbols instead it uses keycodes, this can easily be found with something like xev, so the slash bind, i know that the key is the - on my Portuguese keyboard, so xev gives me keycode: 61

so the bind would be something like
bindcode $mod+61 split horizontal ;; exec $term

documentation:
https://i3wm.org/docs/userguide.html#keybindings

also to get xev one needs to do:
yay -S xorg-xev

edit: this seems like a great solution since in my case, setxkbmap -layout us,pt doesnt work at all, i asked for help on the arch forums, stackexchange, irc, and no one seems to know what is wrong.
Also this would provide an universal setup and end these types of problems to the people who are not using US keyboards

edit edit:

arch wiki gives us a nice xev awk wrapper:
xev | awk -F'[ )]+' '/^KeyPress/ { a[NR+2] } NR in a { printf "%-3s %s\n", $5, $8 }'

it will print the keycodes and keynames.

[LukeSmithxyz]

Yeah, I'm aware of this fix @stormsz . I've been reticent to make that shift because:

• It makes the i3 config pretty intuitive and hard for users to modify and the README might also need to vary based on keyboard layout.
• On keyboards where there are keys shifted over, I believe a lot of the mnemonics are lost or the visual logic of where the keys are.

Now, if the problem is only with the number keys, I suppose I could just switch them over to using bindcode just for them, but I'd want to know what other keys produce problems.

Realistically if there are other lurking interferences, I can make these changes, but I'd want people with non-us keyboards to test it out and see what kinds of problems there might arise first.

[Sercurio]

I installed larbs on void yesterday.

I have a fr azerty keyboard, some of the shortcuts seems ok but first of all Mod + Enter doesn't open a terminal.

Moreover Mod + 3, is also Mod + " on fr layout.