New Kinto config for keyszer, with OptSpecialChars support

[RedBearAK]

As outlined in issue #718 (discussion about switching to keyszer) this PR is intended to offer a wholesale replacement for the Kinto config to take advantage of new features only possible with keyszer (current main as of right now, or v0.7 release or later).

Included (both literally and figuratively with the new "include" feature) is the external module Python file to bring in support for the Option-key special character entry scheme. Both US and ABC Extended layouts.

Numerous other features have already been listed in the #718 thread.

Changes have been made to simplify the diff as much as possible.

[prinzdezibel]

@RedBearAK , can you tell me how to install Kinto from this branch? I'm interested in a keyszer based version of Kinto, because of some quirks with the official distribution.

[RedBearAK]

@prinzdezibel

You can do the method in the keyszer Readme (https://github.com/joshgoebel/keyszer#from-source):

git clone https://github.com/joshgoebel/keyszer.git
cd keyszer
pip3 install --user --upgrade .

That should get keyszer installed with the latest code base and new features.

Keyszer needs to have access to a couple of different device paths, so you'll need to follow the instructions here to set that up using one of the methods described.

https://github.com/joshgoebel/keyszer#system-requirements

I'm super lazy so instead of trying to use the separate "keymapper" user I just put my own user in the input group with:

sudo usermod -a -G input yourusername

The -a part is super important, to avoid removing your user from all other groups (like the sudo group) which would be bad. To really do this safely you should probably have a spare "admin" user set up on your system, in case something goes wrong.

(If your distro doesn't already have the input group you'll have to create it.)

Next you'll really want to stop Kinto if it's running, and disable "Autostart" in the Kinto GUI app or the tray icon menu. So it doesn't try to start the competing xkeysnail systemd service when you reboot.

Then I run this command from the keyszer install instructions and reboot:

cat <<EOF | sudo tee /etc/udev/rules.d/90-keymapper-input.rules
SUBSYSTEM=="input", GROUP="input"
KERNEL=="uinput", SUBSYSTEM=="misc", GROUP="input"
EOF

You really have to reboot. Did you reboot? There's probably a way to get the new rules working without rebooting, but rebooting is the simplest way.

Then, unfortunately with this version of the Kinto config, which is just meant as a proof-of-concept for use with keyszer, you will need to drop the two files attached to this PR in your Kinto config folder (after making a backup of your existing kinto.py config file):

~/.config/kinto

But then you will need to manually do something that the Kinto installer script normally does for you, which is to edit the new kinto.py to enable the correct lines in two different modmap blocks to make it work with your keyboard type.

The blocks look like this. Just search for "modmaps" and scroll down a bit in the config file:

# [Global GUI modmap] Change modifier keys as in xmodmap
modmap("General global modmap",{

    # Key.CAPSLOCK:               Key.RIGHT_CTRL,                 # Caps2Cmd
    # Key.LEFT_META:              Key.RIGHT_CTRL,                 # Caps2Cmd - Chromebook

    # - IBM
    # Key.LEFT_ALT:               Key.RIGHT_CTRL,                 # IBM
    # Key.LEFT_CTRL:              Key.LEFT_ALT,                   # IBM
    # Key.CAPSLOCK:               Key.LEFT_META,                  # IBM
    # Key.RIGHT_ALT:              Key.RIGHT_CTRL,                 # IBM - Multi-language (Remove)
    # Key.RIGHT_CTRL:             Key.RIGHT_ALT,                  # IBM - Multi-language (Remove)

    # - Chromebook
    # Key.LEFT_ALT:               Key.RIGHT_CTRL,                 # Chromebook
    # Key.LEFT_CTRL:              Key.LEFT_ALT,                   # Chromebook
    # Key.RIGHT_ALT:              Key.RIGHT_CTRL,                 # Chromebook - Multi-language (Remove)
    # Key.RIGHT_CTRL:             Key.RIGHT_ALT,                  # Chromebook - Multi-language (Remove)

    # - Default Mac/Win
    # -- Default Win
    # Key.LEFT_ALT:               Key.RIGHT_CTRL,                 # WinMac
    # Key.LEFT_META:              Key.LEFT_ALT,                   # WinMac
    # Key.LEFT_CTRL:              Key.LEFT_META,                  # WinMac
    # Key.RIGHT_ALT:              Key.RIGHT_CTRL,                 # WinMac - Multi-language (Remove)
    # Key.RIGHT_META:             Key.RIGHT_ALT,                  # WinMac - Multi-language (Remove)
    # Key.RIGHT_CTRL:             Key.RIGHT_META,                 # WinMac - Multi-language (Remove)

    # - Mac Only
    # Key.LEFT_META:              Key.RIGHT_CTRL,                 # Mac
    # Key.LEFT_CTRL:              Key.LEFT_META,                  # Mac
    # Key.RIGHT_META:             Key.RIGHT_CTRL,                 # Mac - Multi-language (Remove)
    # Key.RIGHT_CTRL:             Key.RIGHT_META,                 # Mac - Multi-language (Remove)

}, when = lambda ctx: ctx.wm_class.casefold() not in terminals)

# [Global Terminals Conditional modmap] Change modifier keys in certain applications
modmap("Conditional modmap - Terminals",{
    # - IBM
    # Key.LEFT_ALT:               Key.RIGHT_CTRL,                 # IBM
    # # Left Ctrl Stays Left Ctrl
    # Key.CAPSLOCK:               Key.LEFT_ALT,                   # IBM
    # Key.RIGHT_ALT:              Key.RIGHT_CTRL,                 # IBM - Multi-language (Remove)
    # Key.RIGHT_CTRL:             Key.RIGHT_ALT,                  # IBM
    # # Right Meta does not exist on chromebooks

    # Key.RIGHT_ALT:              Key.RIGHT_CTRL,                 # IBM - Multi-language (Remove)
    # Key.RIGHT_CTRL:             Key.RIGHT_ALT,                  # IBM - Multi-language (Remove)

    # - Chromebook
    # Key.LEFT_ALT:               Key.RIGHT_CTRL,                 # Chromebook
    # # Left Ctrl Stays Left Ctrl
    # Key.LEFT_META:              Key.LEFT_ALT,                   # Chromebook
    # Key.RIGHT_ALT:              Key.RIGHT_CTRL,                 # Chromebook - Multi-language (Remove)
    # Key.RIGHT_CTRL:             Key.RIGHT_ALT,                  # Chromebook
    # # Right Meta does not exist on chromebooks

    # - Default Mac/Win
    # -- Default Win
    # Key.LEFT_ALT:               Key.RIGHT_CTRL,                 # WinMac
    # Key.LEFT_META:              Key.LEFT_ALT,                   # WinMac
    # Key.LEFT_CTRL:              Key.LEFT_CTRL,                  # WinMac
    # Key.RIGHT_ALT:              Key.RIGHT_CTRL,                 # WinMac - Multi-language (Remove)
    # Key.RIGHT_META:             Key.RIGHT_ALT,                  # WinMac - Multi-language (Remove)
    # Key.RIGHT_CTRL:             Key.LEFT_CTRL,                  # WinMac - Multi-language (Remove)

    # - Mac Only
    # Key.LEFT_META:              Key.RIGHT_CTRL,                 # Mac
    # # Left Ctrl Stays Left Ctrl
    # Key.RIGHT_META:             Key.RIGHT_CTRL,                 # Mac - Multi-language (Remove)
    # Key.RIGHT_CTRL:             Key.LEFT_CTRL,                  # Mac - Multi-language (Remove)
}, when = lambda ctx: ctx.wm_class.casefold() in terminals)

Find the lines that have comments in each block (GUI and terminals) that match your keyboard type and remove the "# " from the beginning of the line. The ones that say "Multi-language" should remain commented out if you need the right-side Alt key to be "Alt_Gr" for international characters.

You also might want to set the emergency key to stop keyszer to something that is available on your keyboard. You'll find this near the top of the config file:

emergency_eject_key(Key.F16)    # default key: F16

Use any function key that is available on your keyboard, that you normally wouldn't touch. It has to be a single key.

Save the changes, and then you should theoretically be able to start keyszer in a terminal and point it at your config file, like this:

keyszer -w -v -c ~/.config/kinto/kinto.py

If it seems like your terminal is not showing your key presses as they happen, it may be buffering the output, in which case you can add --flush to force the output to always show up immediately:

keyszer --flush -w -v -c ~/.config/kinto/kinto.py

One of the main things that tells me my config is working correctly is if I can open new terminal tabs with Cmd+Tab and then navigate between them with Shift+Cmd+Braces (Left_Brace, Right_Brace). If that set of shortcuts works in a terminal as well as in a tabbed UI like Firefox or Chrome, that's a good sign that everything is good.

If everything seems to be working fine, you can use the emergency key (or Ctrl+C, but that doesn't always work) to stop keyszer, and then you can run it again non-verbosely:

keyszer -w -c ~/.config/kinto/kinto.py

Some people set it up as a systemd service, but I don't really like doing it that way. I just start keyszer in a terminal every time I log in. But I also using the "hacking/venv" setup because I'm constantly messing with keyszer's code.

If you are clever you can easily create a couple of shell scripts to stop and start keyszer. A useful command to kill any keyszer instance running in the background should be:

pkill -f "bin/keyszer"

For my own benefit I'm working on a more advanced config that has features like the ability to automatically work with any keyboard type without switching the keyboard type manually, and a rudimentary installer. But it's not ready yet.

[prinzdezibel]

Works perfectly. Thank you very much for your elaborated explanations. One thing you mentioned didn't work for me, though (and I'm also not sure if it even should work):

Tab-Switching in Chrome works for me via Ctrl+Tab, not Shift+Cmd+Braces. Is Shift+Cmd+Braces even standard behaviour for tab switching in MacOS? (not at my device so I can't test right now)

One more question: Do you know why your changes are not incorporated into the main branch? Is this still WIP?

[RedBearAK]

Works perfectly. Thank you very much for your elaborated explanations.

Impressive. 👍 Even with the elaborate instructions.

One thing you mentioned didn't work for me, though (and I'm also not sure if it even should work):

Tab-Switching in Chrome works for me via Ctrl+Tab, not Shift+Cmd+Braces. Is Shift+Cmd+Braces even standard behaviour for tab switching in MacOS? (not at my device so I can't test right now)

It is, as far as I know. I’ve tried to only have shortcuts that are verified macOS shortcuts, just like Kinto intends. And the original shortcuts shouldn’t stop working. The Braces tab navigation works in most macOS apps with a tabbed UI, including the Finder. Wonder if this version of the config doesn’t have the update to make it work in Chrome.

What’s the result of running this command and then clicking on the Chrome window?

xprop -spy WM_CLASS _NET_WM_NAME

And did it work in the terminal app?

One more question: Do you know why your changes are not incorporated into the main branch? Is this still WIP?

Time. It’s a substantial rewrite (even reorganization) of the Kinto config that would need to be thoroughly checked over before being incorporated. It is a WIP in the sense that if you downloaded the whole branch the Kinto installer wouldn’t correctly install this version of the config, and not just because it hasn’t switched to keyszer. Which is why you had to jump through all the extra hoops to use it.

Usually if you just submit a one-liner update he’ll merge it quickly. But although the content is effectively almost the same, this technically changes thousands of lines and adds a separate include file. The new config I’m working on is a substantial change even on top of this. I have strayed far from the original config. 😂 It may need to be a fork so that some courageous beta testers can verify that it really works, independently of Kinto’s config.

If you have a moment can you open any GUI text editor app and try out the Option-key special characters? Have you ever used them in macOS? Should work the same. Actually it should work right here in the browser as well, in a comment like this.

I’d like to put my current config in a zip and have you put it in a temporary folder under a different name to see if you can run it successfully. Interested? It’s my live config so it should work fine. I just haven’t finished making additional changes that I have planned.

[RedBearAK]

There's nothing specific to Chrome about the Shift+Cmd+Braces even in my current config, but it works. The shortcuts remap to Ctrl+PgUp/PgDn in all GUI apps, and those shortcuts work in addition to the Ctrl+Tab/Shift+Ctrl+Tab shortcuts when I disable the keymapper.

So unless the WM_CLASS of your Chrome browser is not matching, I'm not sure why the Braces tab nav wouldn't be working. But even that doesn't make any sense, because the shortcuts are enabled for all GUI apps in this config.

When using verbose logging there is a line in the log that shows what the combo was and what keymap it was found in. Look for "COMBO:". The keymap name is in braces at the end of the line.

[prinzdezibel]

@RedBearAK , ah sorry. I tried with parenthesis, not the curly braces. It works perfectly with Curly Braces. I'm not using that combo often, so I didn't know about it.

Also German Umlauts work perfectly like on the MacBook. Option u + a for ä.

Thank you so much for your extremely complete Keymapping files. I'm so glad I switched. This issue was driving me mad: https://github.com/rbreaves/kinto/issues/555

It works perfectly now. Thanks!

[prinzdezibel]

I’d like to put my current config in a zip and have you put it in a temporary folder under a different name to see if you can run it successfully. Interested?

Definitely. For now, I don't use Kintotray & GUI, but only your config files in combination with keyszer running as systemd service.

[RedBearAK]

Oh yeah, I did leave that note about keyszer fixing #555. Glad to hear it's working.

The terminology around "parentheses" vs "braces" vs "brackets" seems to be a point of contention, especially internationally. I should have mentioned that they were the keys with square brackets, but the key definition file refers to the keys as LEFT_BRACE and RIGHT_BRACE, and there are no names for the shifted character on the keys, since you have to get to those by adding a Shift key. So the file appears to be calling the square brackets "braces", and I got used to referring to them that way.

Nice and confusing for everyone.

I noticed you're in Germany, are you using a German keyboard layout? Neither of the keymappers seem to work very well with non-US keyboard layouts, because they don't have a built-in understanding of the active layout and there is only one definition (in key.py) of how the key codes map to symbols. I've been researching potential ways of solving this, but it's been remarkably difficult to even do something as simple as detecting the current active keyboard layout.

Also German Umlauts work perfectly like on the MacBook. Option u + a for ä.

That was the intention, although I've only been able to do the special characters scheme for the standard US and "ABC Extended" layouts. So if you're using a German layout you won't find everything in the same place, unfortunately. As long as the ones you need work for you... 👍🏽

Definitely. For now, I don't use Kintotray & GUI, but only your config files in combination with keyszer running as systemd service.

OK. It should be easy to stop the service and just run a manual command to test the other config out. You'll want to see the verbose log to verify that it's all working as expected.

I am in the process of doing a simple tray icon app, very similar to what Kinto has. But it won't need things like the submenu for keyboard type, since that functionality is supposed to be automated now. For me it works even if I have an external Apple keyboard connected to a PC laptop. I can use either keyboard and the modifiers are in the right place. I'm pretty impressed with myself for figuring out how to do it, honestly. 🤣 😆

Just cleaning up some things and I'll post a version of my new config to try.

[RedBearAK]

@prinzdezibel

toshy_alpha_2023-03-02.zip

Here is a zip of a "generic" version of my config. Although with the change to how the modmaps work with no manual intervention, my existing config is very nearly "generic" to begin with. At this point there are just a few global variables that are in a different state than my setup.

You'll probably want to at least edit the main file (toshy.py) to set the emergency eject key the same way you did with this config. If you changed it from F16.

This should unzip into a folder called "toshy_alpha", which you can drop into your ~/.config folder at the same level as the Kinto config folder, then run it with:

keyszer -w -v -c ~/.config/toshy/toshy.py

The end result will theoretically be very similar functionality to running this config. But I can't promise anything. You could be missing some dependencies from something I've added, or a custom function won't work as expected. I've only run this on a couple of different systems so far.

[RedBearAK]

One of the "include" files in the config_includes folder is for custom user shortcuts, like hardware function key remaps that may be specific to a laptop keyboard. Or new keymaps that haven't been integrated into Kinto yet. The idea will be to avoid overwriting that file in future upgrades, so user customizations outside the main config file don't get clobbered.

Oh, and you can use the "ABC Extended" keyboard layout for the Option-key special characters by switching to it with Shift+Opt+Cmd+X. In case you care about that.

keymap("OptSpecialChars toggles", {
    C("Shift-Alt-RC-o"):        disable_optspec(),      # Disable all layouts
    C("Shift-Alt-RC-u"):        toggle_optspec_US(),    # Toggle the US layout
    C("Shift-Alt-RC-x"):        toggle_optspec_ABC(),   # Toggle the ABC Extended layout
}, when = lambda ctx: ctx.wm_class.casefold() not in terminals)

[RedBearAK]

Forgot to mention, the way that the auto keyboard type works is it looks for either your device name in a list that corresponds to the keyword, or tries to regex match the keyboard type keyword within the device name.

So if your keyboard device (should see it in the log when using any remapped combo) is not being treated as the right type, you may need to add the device name to one of the lists.

Later this will not be necessary for most Windows/PC type keyboards, as that will be the default if the other tests for keyboard type fail.

# Lists of keyboard device names, to match keyboard type
keyboards_IBM = [
    # Add specific IBM-style keyboard device names to this list
    'IBM Enhanced (101/102-key) Keyboard',
    'IBM Rapid Access Keyboard',
    'IBM Space Saver II',
    'IBM Model M',
    'IBM Model F',    
]
keyboards_Chromebook = [
    # Add specific Chromebook keyboard device names to this list
    'Google .* Keyboard',
    '.* Chromebook Keyboard',
]
keyboards_Windows = [
    # Add specific Windows/PC keyboard device names to this list
    'AT Translated Set 2 keyboard',
]
keyboards_Apple = [
    # Add specific Apple/Mac keyboard device names to this list
    'Mitsumi Electric Apple Extended USB Keyboard',
]

kbtype_lists = {
    'IBM': keyboards_IBM, 
    'Chromebook': keyboards_Chromebook, 
    'Windows': keyboards_Windows, 
    'Apple': keyboards_Apple
}

[RedBearAK]

@prinzdezibel

New version of keyboard type function should give good support for automatically enabling the correct modmaps with many keyboards, especially "Apple" or "Windows" types, without needing to put the specific device name in one of the lists. Did not expect it to be such a difficult problem.

toshy_alpha_2023-03-04.zip

[JohnnyMarnell]

I got the keyszer + config to work via the comment instructions (I'm on xubuntu and had trouble making sure xinputsnail didn't start/conflicted, so I ended up backing up the ~/.config/kinto dir, and restoring it after running its uninstaller). Thanks a million!

[RedBearAK]

I got the keyszer + config to work via the comment instructions

Nice. 👍🏽

Let me know if you ever give the new "alpha" config a try, from the comment above. I assume you just used the config files attached to this PR.

[prinzdezibel]

I noticed you're in Germany, are you using a German keyboard layout?

No, I'm using standard us layout, because it's better suited for programming. On a regular german keyboard the brackets and some other central keys would be sacrificed for the umlauts. But I'd rather have them available via option-key special characters combo.

[RedBearAK]

I'm using standard us layout, because it's better suited for programming. On a regular german keyboard the brackets and some other central keys would be sacrificed for the umlauts. But I'd rather have them available via option-key special characters combo.

Very interesting.

Well, then you're very lucky, since the Option-key special characters and "dead keys" will all be in the correct places for you as long as you continue to use the US layout. Well, they'll still be in the same places if you change the keyboard layout, since the keymapper won't recognize the difference. 😆 So if you know where they are on the US layout you'll always be able to use them as if you were using the US layout. On a real Mac the special characters would move around when the layout changes, but that's not currently the way it works with this config. Maybe someday.

You're the first person that I know of who might actually get some good use out of the optspecialchars.py additions that I made. Nice. 🎉 Took me quite a while to finish that whole thing. Quite tedious work, looking up about 650 characters in online Unicode tables. Oh, and pushing the keyszer developer to help me add a Unicode processor function to the keymapper. Without that it wouldn't be possible.

But I'm glad I did it, especially for international users who are OK with using the US layout like you do. In fact, cases like yours are one of the main reasons I wanted to implement the Option-key special characters.

Thanks for letting me know. 👍🏽

[JohnnyMarnell]

Two observations of possible bugs (curious about others' experiences?) :

1. pressing Ctrl alone seems to act as "Spotlight" (brings up quick launch window in Xubuntu; same behavior as currently pressing Command_Equivalent_Alt-Space now, or Windows_Meta alone did before Kinto)
2. Command_Equivalent_Alt-Left_Click in Chrome/Firefox no longer works for "Open link in new tab"

[14to9]

Hey @RedBearAK -- I thought I'd try out your config (I'm a regular user of internation special characters) and thought you'd appreciate that the latest zip has an extra .py extension on a file: config_includes/optspecialchars.py.py

Meanwhile, I look forward to the experience! So far, so good on addressing my issue ( #555 ) :trophy:

[14to9]

@RedBearAK I've noted this odd behavior when producing the "chorded?" international chars like é or ü : the decorative piece is printing additional to the chorded character:

Test

Press option + u (for umlaut) Release and press u (for ¨ü). Expected ü, got ¨ü

Get the same behavior on other similar marks ( ˆ ´ etc )

[RedBearAK]

@14to9

thought you'd appreciate that the latest zip has an extra .py extension on a file: config_includes/optspecialchars.py.py

Weird. Have no idea how that happened. Thanks for letting me know.

odd behavior when producing the "chorded?" international chars

They're referred to as "dead keys" in most places, from what I've found.

It's supposed to be mimicking what happens on macOS, printing the diacritic, highlighting it, then replacing it when (if) you give it the appropriate key to put the accent on. Since the "u" is part of the group that belongs with an umlaut, that initial diacritic character shouldn't be left on the screen. But if you were to use a "wrong" key after the dead key, leaving the diacritic character there would be normal.

I think I might have an idea what's happening. If you have the latest keyszer installed, you should be able to test this new API feature that might help:

throttle_delays(
    key_pre_delay_ms    = 0,    # default: 0 ms, range: 0 to 150 ms, suggested: 1-50 ms
    key_post_delay_ms   = 0,    # default: 0 ms, range: 0 to 150 ms, suggested: 1-100 ms
)

I developed this new API function with the keyszer dev to deal with some macro problems that have caused issues for me in various ways. For a bare metal install (not in a virtual machine), I suggest starting with 2ms for the "pre" delay and 4ms for the "post" delay.

The way the special characters work involves Unicode sequences (like Shift-Ctrl-u, 2, 0, 2, 1, Enter) as well as macros to help imitate the dead keys sequences. Something may be going wrong in the way those macros work.

Please let me know if this helps fix the issue.

Oh, and what distro and desktop environment are you on?

[14to9]

@RedBearAK Success! The delay adjustments ( of 2 and 4) result in the expected diacritical replacements. :raised_hands:

I'm running PopOS 22.04 LTS on an Intel NUC, and a Mac/Windows (Hexgears Gemini Dawn) keyboard.

I KVM back and forth to an Intel Mac Mini so even the differences can sometimes be jarring lol

Speaking of, here's another adventure candidate: how can we get the MacOS Command-Backspace "don't save*" dialog behavior? I'm guessing it's probably just not a supported instruction in Linux?

• https://discussions.apple.com/thread/4429431

[RedBearAK]

Two observations of possible bugs (curious about others' experiences?) :

1. pressing Ctrl alone seems to act as "Spotlight" (brings up quick launch window in Xubuntu; same behavior as currently pressing Command_Equivalent_Alt-Space now, or Windows_Meta alone did before Kinto)

@JohnnyMarnell

Since the keymapper remaps modifier key locations for each keyboard type, I have often found it very helpful to refer to the "logical" keys and the "physical" keys, to make the troubleshooting process less confusing for me.

I assume what you mean by this is that you press the physical Ctrl key and it acts like the Super/Meta/Win key previously acted? If you're on a PC keyboard (and not in a terminal app), that would be normal. The Super key logically gets shifted to the left physical Ctrl key, while the physical Super/Meta/Win key becomes Alt (i.e., Option) and the physical Alt key becomes RIGHT_CTRL.

So, you just need to track down the setting in Xfce that's opening that feature and change it to using Alt+F1 (that's what the Cmd+Space equivalent should be getting mapped to).

This is similar to the way Kinto has to disable the special overlay key shortcut in GNOME, that also uses Super by itself.

This feature may be provided by an app that's not built-in to Xfce, so the shortcut it's binding to might be a setting in the app itself. I remember I used to have to fix the shortcut that opened the Linux Mint app menu by right-clicking on the actual widget on the panel and editing its preferences. The shortcut wasn't found in the main shortcut config control panel.

2. Command_Equivalent_Alt-Left_Click in Chrome/Firefox no longer works for "Open link in new tab"

Both Cmd+Click and Cmd+Alt+Click are working for me. But I'm on a laptop with a touchpad, and I have to set the "suspend" timeout in the config from 1 second to 0.1 second. And that necessitates setting ui.key.menuAccessKeyFocuses to False in Firefox.

You don't say which version of the config you're using. The new "alpha" I posted in the comments?

[RedBearAK]

Success! The delay adjustments ( of 2 and 4) result in the expected diacritical replacements. raised_hands

@14to9

Fantastic. I'm glad that was the source of the problem, not something more complicated. Another confirmation that implementing the throttling API was a good idea.

If you fed the string processor function [ST() in this config] a long string full of Unicode characters and shifted characters, you probably would have found that some of them would come out wrong, or sometimes the macro would even stop coming out partway through. Without the throttling in place.

You can try cutting the delays down to 1ms and 2ms and you may still find it effective. Or you can leave it the way it is.

In virtual machines I've found that those delays have to be more like 40ms/70ms to get reliability from macros and shortcut combos.

I'm running PopOS 22.04 LTS on an Intel NUC, and a Mac/Windows (Hexgears Gemini Dawn) keyboard.

I KVM back and forth to an Intel Mac Mini so even the differences can sometimes be jarring lol

That's pretty much the perfect scenario for something like Kinto, where the Linux machine sees the same keyboard device. It's still difficult to get the remapping to work well running over any kind of remote access software, but a physical KVM would be different. You're lucky.

Speaking of, here's another adventure candidate: how can we get the MacOS Command-Backspace "don't save*" dialog behavior? I'm guessing it's probably just not a supported instruction in Linux?

* https://discussions.apple.com/thread/4429431

I believe that I looked at that in the past and it's not something that can really be done in Linux. Possibly could be done in Windows with AutoHotkey, which is far more powerful and has access to a lot more information about the window/dialog.

But in Linux, the only pieces of information available about the window are the application "class" and now with kesyzer the window title/name. This has very limited usefulness in identifying specific child windows or dialogs. On top of that, the different GUI frameworks used in Linux mean that every app does this type of Save dialog differently, if they even have the "Discard" or "Don't save" button at all.

So implementing this specific shortcut is basically not feasible, or at least not worth the trouble for very limited results.

I've found the best way to deal with the loss of this shortcut is to get used to Tabbing until the "Discard" button is highlighted and hitting Space to activate the button. It's very quick. And also works in macOS, as far as I know. Well, you may need to enable the "tab between all controls" setting in the keyboard preferences in macOS for that to work. They keep changing the name of that setting, so it depends on what version of macOS you're using.

[JohnnyMarnell]

Thanks for the quick reply! Apologies for #1, I re-checked using plain Kinto and that is same behavior. (Sounds like it might not be the case for GNOME, but physical Ctrl and physical Alt-Space do the same "quick launch/whisker" menu behavior for stock Kinto).

Thanks for the pointer on #2, didn't realize timeouts are now a factor with keyszer I guess -- bit of a bummer to learn, what other cases should I be worried about / can you explain more? e.g. Does it not factor for keyboard-only combos? Should I expect this to matter for any combos with mouse actions plus keyboard (modifier or other)? Other cases? Either way, when and why would 1 second be a sensible default verses your 0.1s?

And I'm using this PR's config (have un-commented back in the # Default Win lines as the kinto installer does), Xubuntu 22.04, Asus M415 (🤮 I know), its terrible trackpad and slightly less terrible L to R: ctrl-fn-Win/Meta-alt-spacebar keyboard

[RedBearAK]

Thanks for the quick reply! Apologies for #1, I re-checked using plain Kinto and that is same behavior. (Sounds like it might not be the case for GNOME, but physical Ctrl and physical Alt-Space do the same "quick launch/whisker" menu behavior for stock Kinto).

@JohnnyMarnell

Yeah, I don't know what is binding the Ctrl key to do that. The keymapper software literally doesn't allow a modifier key by itself to be used as a shortcut. If you try to load a config with that kind of "combo" without a real key involved, it will crash with an error. So that binding of the logical Super/Meta/Win key is somewhere in Xubuntu.

Thanks for the pointer on #2, didn't realize timeouts are now a factor with keyszer I guess -- bit of a bummer to learn, what other cases should I be worried about / can you explain more? e.g. Does it not factor for keyboard-only combos? Should I expect this to matter for any combos with mouse actions plus keyboard (modifier or other)? Other cases? Either way, when and why would 1 second be a sensible default verses your 0.1s?

I don't really understand how the suspend works, actually. The idea was to temporarily keep an application like Firefox from seeing that you pressed the Alt key, so that the menu bar doesn't get triggered. Somehow touchpad clicks don't get treated like mouse clicks (from what the keyszer dev said) so the suspend doesn't work as intended. Unless you hold the key until the suspend timeout is over, then the Mod+click would work.

So I found that I had to trim it down to 0.1 seconds. Because I do a lot of fast Mod+clicking.

That's really all I know about it. I go through the necessary steps to disable activation of the menu bar with Alt in Firefox and VSCode, and then the short suspend doesn't really cause me any issues.

And I'm using this PR's config (have un-commented back in the # Default Win lines as the kinto installer does), Xubuntu 22.04, Asus M415 (vomiting_face I know), its terrible trackpad and slightly less terrible L to R: ctrl-fn-Win/Meta-alt-spacebar keyboard

I'm on a cheapo Acer Aspire 5 Slim (Ryzen) that's probably very similar.

Have you enabled the Xfce-specific lines in the config? My newer config moved them into an "override" keymap that should do the job automatically, but I haven't tested it.

keymap("GenGUI overrides: Xfce4", {
    C("RC-Grave"):             [bind,C("Super-Tab")],           # xfce4 Switch within app group
    C("Shift-RC-Grave"):       [bind,C("Super-Shift-Tab")],     # xfce4 Switch within app group
    C("RC-Space"):              C("LC-Esc"),                    # SL- Launch Application Menu xfce4
    C("RC-F3"):                 C("C-Alt-d"),                   # SL- Show Desktop xfce4
    C("RC-H"):                  C("Alt-F9"),                    # SL - Minimize app xfce4
}, when = lambda ctx: matchProps(not_lst=remotes_lod)(ctx) and DESKTOP_ENV == 'xfce4' )

You say Cmd+Space opens the Whisker menu, but those lines aren't enabled by default, so that's kind of curious. Unless you enabled them or set your Whisker menu shortcut to Alt+F1.

[RedBearAK]

@JohnnyMarnell

OK, here's what seems to be going on in Xubuntu (I don't know how much of this is default Xfce or specific to Xubuntu).

There are actually three different shortcuts set up in the Keyboard settings in Xubuntu:

xfce4-popup-applicationmenu    Alt+F1
xfce4-popup-whiskermenu        Ctrl+Escape
xfce4-popup-whistermenu        Alt+Pause

Then there is a separate utility running called xcape that appears to be remapping the Super key press to Alt+Pause. You'll see it if you do ps ax | grep -i xcape in the terminal. I haven't heard of it before, but it appears to be a modifier key remapper.

So that's why the default Kinto shortcut remap of Cmd+Space to Alt+F1 is working on Xubuntu, because the applicationmenu shortcut is just opening the default Whisker menu. On Linux Mint they use their own custom menu applet, so the situation is a little different.

To keep the Super key from activating the Whisker menu, you can either figure out how to keep xcape from starting automatically, or just get rid of the shortcut that responds to Alt+Pause. But then you'd still have every Super key press (by itself) remapping to Alt+Pause in the background.

Ah, there is a startup item in Xubuntu called "Bind Super Key". It runs the xcape command with the argument to remap the Super_L key. You can just go into "Session and Startup" and uncheck the box next to that item, and that Super remap should stop happening. Do pkill -f "xcape" to kill the existing process and you should be good.

[SebCorbin]

Hey there, I'm kinda annoyed with the fact that you can't "chain" currently shortcuts (keep a key modifier pressed), so I'm willing to try keyszer, is this PR still ongoing/usable? What's the status? Do you need international testers? (French Apple Azerty keyboard user here)

[RedBearAK]

Hey there, I'm kinda annoyed with the fact that you can't "chain" currently shortcuts (keep a key modifier pressed), so I'm willing to try keyszer, is this PR still ongoing/usable? What's the status? Do you need international testers? (French Apple Azerty keyboard user here)

@SebCorbin

You may want to look at my project, where I took this keyszer config as the basis. But I am afraid that even with my project the only complete fix for a non-US keyboard is still going to be modifying the key definition file for the keymapper, which no one has had the patience to do yet. On the other hand, chaining shortcuts works well with keyszer.

This will take you to the GitHub repo for Toshy:

https://toshy.app