macOS Sierra Support #10
Conversation
Karabiner doesn't currently run on macOS Sierra. Until it does, perhaps we can use Karabiner-Elements and Hammerspoon to get the functionality that we used to get from Karabiner. For starters, let's configure caps lock so that we can: - Tap caps lock for escape - Press caps lock plus and another key to trigger *control* plus that other key (e.g., "caps lock + e" to trigger "control + e" to move to the end of the line) Depends on: - Hammperspoon (http://www.hammerspoon.org) - Karabiner-Elements (https://github.com/tekezo/Karabiner-Elements)
Credit goes to https://github.com/rtoshiro/hammerspoon-init for the comments used to visually describe the window layouts.
caps lock + r needs to be available in the terminal to trigger control + r. So, change the keybinding that's used to reload the hammerspoon config from caps lock + r to caps lock + `, and make caps lock + r trigger control + r.
- Translate h/j/k/l to up/down/left/right. - When caps lock is held down, treat 'a' as 'alt' and 's' as 'command'. Therefore, for example, when pressing caps lock plus 's' plus 'h', it becomes 'command' plus 'left'.
- Add support for core (S)uper (D)uper Mode features. - Remove similar features from BetterCapsLock Mode. This frees us to use caps lock as control in more situations (e.g., we'll be able to translate caps lock + a to conrol + a to go to the beginning of the line).
|
3fb5e77 adds support for "(S)uper (D)uper Mode" on macOS Sierra. Most of the pre-Sierra features are available:
Prior to Sierra, this functionality ☝️ relied on Karabiner's Simultaneous VI Mode. Since Karabiner-Elements doesn't yet support Simultaneous VI Mode, this pull request implements the functionality via Hammerspoon. /fyi @pengwynn @adamyonk @spicycode: This might be of interest to you. ⌨️ |
Hammerspoon doesn't appear to have a way to indicate which screen should receive the drawing. It seems to always go to the primary screen. If you connect or disconnect a monitor while Hammerspoon is running, your primary screen may change. Since we use the dimensions of the primary screen to calculate the coordinates for the status message, and since the coordinates of the primary screen can change, we need to dynamically determine the coordinates of the status message each time we display it (or, we need to recalculate the coordinates any time the primary screen changes). For now, the easiest approach seems to be to lazily construct the status message drawings each time we need to display them.
Prior to this change, yubiswitch couldn't disable the yubikey. With this change, yubiswitch can once again enable/disable the yubikey.
Update: I've started using this branch full-time, with mostly positive results. So far, I'm only noticing one issue: (S)uper (D)uper mode occasionally fails to trigger some actions. For example, if I hit I'll continue using this branch for the rest of this week. If things go smoothly, I'll move on to updating the README, and then I'll merge this branch. |
|
Pulled down the latest this morning, it's working great! I especially like the super duper and window layout mode notifications. Regarding your tab-switching bugginess comment, I noticed that switching tabs would get tripped up for me if the tab I switched to had focus on an input when I left it - that input would start capturing everything instead of continuing to move between tabs. I'm not sure if there would even be a way to keep that from happening, but I wonder if that was why it was happening for you? Anyway, it is working splendidly for me - awesome work! |
3598ce5 and 45ad832 added a hotkey to exit WindowLayout Mode and Markdown Mode respectively. But, that original implementation created a new binding for the hotkey every time the mode was entered. Therefore, if you entered WindowLayout Mode n times, you end up with n hotkey bindings for exiting WindowLayout Mode. After a while, WindowLayout Mode would get really slow, due to all the setup time required to setup and teardown each of those many bindings. 😓 With the changes in this commit, we only create the binding once. 😅
We don't seem to be getting any benefit from using the lower-level approach, so let's switch to using hs.eventtap.keyStroke.
|
@adamyonk: Thanks for all your testing and feedback this pull request. Your enthusiasm and support made this even more fun! 🍻 If you notice any issues or have any feedback, I'm all ears. 💟 |
|
Now that this pull request is merged, if anyone is looking for the pre-Sierra bits, the v1.0.0 release is suitable for use on OS X El Capitan (10.11), and it probably works on OS X Yosemite (10.10) and OS X Mavericks (10.9) as well. The changes in this pull request (which are present in the new v2.0.0 release), are suitable for use on macOS Sierra (10.12) and OS X El Capitan (10.11). ✌️ |
|
I'm over a month late, but a big 👍 and thank you @jasonrudolph. I currently rely on parts of this in El Capitan and have delayed upgrading to Sierra because of it. Now I have a clear path. Much appreciated. |
|
I'm really digging the project too! |
|
Wow. Just found this just after I go all the way to solve it in hardware level! 🙈 |
This setup has historically relied heavily on Karabiner. According to the Karabiner site:
I have high hopes for all a full-featured Karabiner coming to Sierra 🤞, but in the meantime, I'd ❤️ to have as much of this setup working on Sierra as possible.
This branch represents a work-in-progress attempt to port the majority of this repository's pre-Sierra functionality to Sierra. Presently, the tools available on Sierra lack the power and flexibility available in Karabiner. Given those limitations, porting the previous functionality to Sierra will likely involve compromises. It's unlikely to be an exact port.
TODO