For French, I like having a 4th alphabetical key under the middle finger (for instance, move the innermost thumb key a little upward so that is contiguous with the middle finger column). This allows having all the most common characters in the main layer (also using most of the outer pinky columns for this purpose).
Otherwise does this 2 row cluster work well for you? (In particular the upper row)
Concerning the technical trick with xmodmap, I have the feeling you are adding much complexity just for the sake of using qmk’s graphical configurator.
Since you are already using xkb (obviously, since there isn’t any serious alternative under X11 or Wayland!), why not configure everything in xkb layout? This way you can configure any existing character without any strange workaround or third party tool! Then your use qmk just for fancy stuff (layers, combos, hold-tap, … ).
The usual argument against xkb is that you cannot bring your keyboard around and have it ready to use on any machine. But since you are using xmodmap, I assume it is not a concern for you, is it?
I could cut it off. The 5 innermost keys aren’t even used, and the one left over is just for (rarely) pressing alt, and that’s only on the left half. As for the top matrix row, it’s the same situation: I only use it for function keys which I only use for switching tty’s, and I know I would always ask myself “wait, how do I press f1/f2?” The outer keys are used for the enter key and print screen, which leaves 4 unused keys. That’s:
5 useless keys for the left thumb
6 for the right thumb
6 on each half for the top row which could be moved yo another layer, making the keeb smaller while only having to remember 12 logically placed f keys
4 outer keys on the 3 bottom rows
= 27 keys that could be removed. Yikes.
Now onto the xmodmap stuff: when I need to use the keyboard on a new computer, it will almost always be on an X11 Linux one, as that’s what my high school computers for IT use (the one specific to the classes I’m taking), and also what I managed to get my family to use.
This means I’ll always be able to add the xmodmap stuff, plus it poses no problem to other users of the same account (if applicable) as it uses f13+ keys which nobody else would use (most people don’t even know these keys exist).
I also like not having to change my keymap from us especially when doing work on server hardware (I sometimes physically access a think centre used for backups at renn.es, shameless plug).
The configurator is not even really my thing anymore, I only ever change the config through the file nowadays.
My first ergo split was a Kimiko (roughly the same as a Sofle v2) which also had this num row I quickly stopped using (I ended up affecting it to F keys, still useless anyway; even for switching VTs I tended to use F keys from one of the layers).
My current daily driver is a 3x6 dactyl with a 4th key under middle and ring finger columns and… a 6 keys (2 rows) thumb clusters. All 6 keys can easily be reached because of the 3D shape. I would say only a couple of keys among the 50 are not really useful, hence it is the sweet spot for me now (for a sculpted keyboard anyway; for a flat one, I have to make it work with smaller thumb clusters).
Anyway the similar layout of the thumb clusters and similar goals (Linux user; typing in French) made me want to comment :).
Yeah, a dactyl kinda defeats the point of having a small keyboard. Soon I’ll try to make a 36-key split with some way to link the two parts to make it usable on laptops for example (rn it’s comically large when using a laptop: I need to put the two halves on the side plus a mouse if I don’t want to use the touchpad). I’ll also use sockets for everything (switches & XIAO controllers) so that the next one I make doesn’t cost as much.
Unless I am mistaken, keyd is a kernel level input remapper (like kmonad and kanata). So it is a lower level component: even if you use keyd, xkb will still be there, downstream. The situation would be roughly the same as with xmodmap… except it won’t even be enough!
Indeed, this method consists in mapping scan codes to other scan codes. At this level, there is not the notion that a key produces a character yet.
Hence concretely, kernel level input remapping (like QMK, btw) cannot be used to map a key to a character that is not already declared in a higher level component (usually in xkb or xcompose, but it can also be a another component using X11 API, such as xmodmap, for instance).
Edit: to make it more clear, in the end, it is the application who decides what character should be displayed. Typically, for doing so, the application relies on libraries from its toolkit, which implement either X11 or Wayland text input protocols; using standard keycode-to-character translation libraries (i.e., most notably, libxkb). To add new characters in a keymap, these characters need, in the end, to be produceable as the output of these libraries.
Very nice keyboard!
For French, I like having a 4th alphabetical key under the middle finger (for instance, move the innermost thumb key a little upward so that is contiguous with the middle finger column). This allows having all the most common characters in the main layer (also using most of the outer pinky columns for this purpose).
Otherwise does this 2 row cluster work well for you? (In particular the upper row)
Concerning the technical trick with xmodmap, I have the feeling you are adding much complexity just for the sake of using qmk’s graphical configurator. Since you are already using xkb (obviously, since there isn’t any serious alternative under X11 or Wayland!), why not configure everything in xkb layout? This way you can configure any existing character without any strange workaround or third party tool! Then your use qmk just for fancy stuff (layers, combos, hold-tap, … ).
The usual argument against xkb is that you cannot bring your keyboard around and have it ready to use on any machine. But since you are using xmodmap, I assume it is not a concern for you, is it?
I could cut it off. The 5 innermost keys aren’t even used, and the one left over is just for (rarely) pressing alt, and that’s only on the left half. As for the top matrix row, it’s the same situation: I only use it for function keys which I only use for switching tty’s, and I know I would always ask myself “wait, how do I press f1/f2?” The outer keys are used for the enter key and print screen, which leaves 4 unused keys. That’s:
= 27 keys that could be removed. Yikes.
Now onto the xmodmap stuff: when I need to use the keyboard on a new computer, it will almost always be on an X11 Linux one, as that’s what my high school computers for IT use (the one specific to the classes I’m taking), and also what I managed to get my family to use. This means I’ll always be able to add the xmodmap stuff, plus it poses no problem to other users of the same account (if applicable) as it uses f13+ keys which nobody else would use (most people don’t even know these keys exist). I also like not having to change my keymap from us especially when doing work on server hardware (I sometimes physically access a think centre used for backups at renn.es, shameless plug). The configurator is not even really my thing anymore, I only ever change the config through the file nowadays.
My first ergo split was a Kimiko (roughly the same as a Sofle v2) which also had this num row I quickly stopped using (I ended up affecting it to F keys, still useless anyway; even for switching VTs I tended to use F keys from one of the layers).
My current daily driver is a 3x6 dactyl with a 4th key under middle and ring finger columns and… a 6 keys (2 rows) thumb clusters. All 6 keys can easily be reached because of the 3D shape. I would say only a couple of keys among the 50 are not really useful, hence it is the sweet spot for me now (for a sculpted keyboard anyway; for a flat one, I have to make it work with smaller thumb clusters).
Anyway the similar layout of the thumb clusters and similar goals (Linux user; typing in French) made me want to comment :).
Yeah, a dactyl kinda defeats the point of having a small keyboard. Soon I’ll try to make a 36-key split with some way to link the two parts to make it usable on laptops for example (rn it’s comically large when using a laptop: I need to put the two halves on the side plus a mouse if I don’t want to use the touchpad). I’ll also use sockets for everything (switches & XIAO controllers) so that the next one I make doesn’t cost as much.
You say there is no serious alternative: did you check out keyd?
Unless I am mistaken, keyd is a kernel level input remapper (like kmonad and kanata). So it is a lower level component: even if you use keyd, xkb will still be there, downstream. The situation would be roughly the same as with xmodmap… except it won’t even be enough!
Indeed, this method consists in mapping scan codes to other scan codes. At this level, there is not the notion that a key produces a character yet. Hence concretely, kernel level input remapping (like QMK, btw) cannot be used to map a key to a character that is not already declared in a higher level component (usually in xkb or xcompose, but it can also be a another component using X11 API, such as xmodmap, for instance).
Edit: to make it more clear, in the end, it is the application who decides what character should be displayed. Typically, for doing so, the application relies on libraries from its toolkit, which implement either X11 or Wayland text input protocols; using standard keycode-to-character translation libraries (i.e., most notably, libxkb). To add new characters in a keymap, these characters need, in the end, to be produceable as the output of these libraries.