Thanks Andreas, I had missed this in the previous discussion.
First, I must say it's a very clever hack :)
I have not looked at it deeply yet, but I have some initial questions:
- Can you describe a bit how you imagine the changes to xkeyboard-config would look with this approach?
- Do you think this can be done in a backwards compatible way? As far as xkbcommon is concerned, I am only interested in this scenario: old library (unaware of the new LockMods options) & new keymap (in textual form, modified with the new flags).
X has more compatibility concerns, xkbcomp/client/server/libxkbfile/protocol/Xlib/etc, but allow me to ignore that for now.
BTW: xkbcommon already supports noLock/noUnlock in LockMods (unlike xkbcomp), based on your work[1]. So I hope the approach does not rely on these not already working :)
Thanks Andreas, I had missed this in the previous discussion.
First, I must say it's a very clever hack :)
I have not looked at it deeply yet, but I have some initial questions:
- Can you describe a bit how you imagine the changes to xkeyboard-config would look with this approach?
- Do you think this can be done in a backwards compatible way? As far as xkbcommon is concerned, I am only interested in this scenario: old library (unaware of the new LockMods options) & new keymap (in textual form, modified with the new flags).
X has more compatibility concerns, xkbcomp/ client/ server/ libxkbfile/ protocol/ Xlib/etc, but allow me to ignore that for now.
BTW: xkbcommon already supports noLock/noUnlock in LockMods (unlike xkbcomp), based on your work[1]. So I hope the approach does not rely on these not already working :)
[1] https:/ /github. com/xkbcommon/ libxkbcommon/ commit/ 7c5e79159b5f5cd 533a078c7672705 e2ffa0a798