Identify keyboard type before swapping modifier keys

[RedBearAK]

The keyboard remapper that I normally use to get macOS keyboard shortcuts in Linux (Kinto.sh by Ben Reaves) has a procedure in the installer that asks for you to press the key 2nd to left of the space bar. This allows the install script to identify whether you are on a PC keyboard (Super/Win key code), an Apple keyboard (Option key code), a Chromebook keyboard, or an IBM keyboard with no with no Super/Win key. The Kinto GUI also lets you change the keyboard type on the fly, for when you need to switch physical keyboards.

I tried to test Meta Mac on a 2007 white MacBook3,1 which of course has an actual Apple keyboard with the Command key in the "correct" place for Mac keyboard shortcuts. This doesn't work well with Meta Mac because (I assume) it's currently only designed to turn a PC keyboard into behaving like a Mac keyboard, by swapping the Control key with the Alt key.

For Meta Mac to work for people who run Linux on actual Macs (I've got Ubuntu 21.10 on this MacBook), and for those who use Apple external keyboards connected to PC laptops, or for Chromebook users running Linux and other scenarios, you'll need to provide a way to specify or identify the type of keyboard the user is on, and a way to change the keyboard type if necessary.

[canadaduane]

Great feedback, thanks!
May I ask why you're interested in Meta Mac when you have Kinto.sh at your disposal? (I'm just curious--I discovered kinto.sh only after writing Meta Mac, so I'm still learning a lot in this key remapping space).

[RedBearAK]

@canadaduane

The answer to that is very simple, but with a long backstory: I want Linux to be more inviting to Mac users.

Kinto.sh helps with that, but it has the issue of not being able to run on Wayland yet, and a lot of Linux users for some reason think they really need to run Wayland now, despite all of its remaining bugs and issues. So I'm always looking out for options besides Kinto that might be able to do the same thing.

I got introduced to Mac-style keyboard shortcuts when using BeOS around the turn of the millenium. BeOS was originally designed to be an alternate operating system to run on Mac hardware. They ported it to PCs and kept the same keyboard shortcut scheme, using the Alt key as the basis of the shortcuts. I found the shortcuts much more intuitive than anything I'd tried to use in ten years of growing up with Windows.

When BeOS development ended, I moved to the fledgling Mac OS X, and I've been primarily using Macs ever since. I felt immediately at home because I could use all the same keyboard shortcuts that I was using in BeOS, since they had based their shortcuts on classic Mac OS. I ended up using at least a couple of dozen Mac keyboard shortcuts so frequently that they are now embedded in my muscle memory, like my touch typing skills. That makes it incredibly annoying to move over to a Linux computer and clash with its Control-key based Windows-like keyboard shortcuts. But the developers of Linux DEs don't seem to care to implement a proper keyboard shortcut scheme changer, so projects like Kinto and Meta Mac have to exist.

As I mentioned on Reddit, Kinto can also solve that problem on Windows. The dev maintains both the Linux and Windows versions together, offering most of the same keyboard remaps for both.

I don't know if you're going to go down the route that Kinto has taken and do a lot more application-specific remapping, or just stick with the simple modifier remapping and fixing copy/paste in terminals (which accomplishes quite a lot already), but I'm sure someone will find your project useful. For me, I don't think I can live without all the extra remapping in Kinto that fixes web browser and file browser behavior and many other things I can't even recall anymore.

I also went to ridiculous lengths to use Kinto's xkeysnail remapping to fix the behavior of a weird Acer laptop keyboard that has arrow keys with media key functions instead of the usual PgUp/PgDn/Home/End. And bypass a GTK bug that refuses to respond to shortcuts that use the numpad navigation functions. That was a whole saga that I documented over in the Kinto issues.

And of course, as I mentioned on Reddit, I got so irritated with Linux file managers that I implemented shortcut remapping for every GUI Linux file manager I could find to make them all behave as much as possible like the Finder. That's made me a lot more comfortable actually using Linux for extended lengths of time. The Finder mods have been merged with the Kinto master, so if you install Kinto you will see Finder-like keyboard behaviors from Nautilus, Nemo, Caja, Dolphin, pretty much any common Linux file manager.

The End.

[canadaduane]

We have a lot in common! Although I only drooled over BeOS and never had a chance to use it. When Mac came around, I was at first surprised that any serious software developer would use it, but a Rubyist convinced me back in 2005 and I've been using it ever since (until this year). I'm slowly make the switch from a 2015 MacBook Pro to a 2021 Framework laptop (and I've never been more excited!)

The motivation for me to switch is primarily to support free-culture, and a desire to improve systems for others wherever I go.

Ok, back to Meta Mac: I discovered through writing this package that there are a LOT of key remapping softwares out there for Linux! In fact, I just published this article:

https://medium.com/@canadaduane/key-remapping-in-linux-2021-edition-47320999d2aa

Having spoken with the author of keyd (rvaiya/keyd#48) and solved the last remaining issue, I'm excited to try building on that infrastructure. The two things that keyd could use to assist us in this effort are:

1. Mouse integration (e.g. cmd+click type stuff), and
2. Active Window events
3. [wishlist item:] a GUI for keyd

According to what I've learned so far, getting the "Active Window" on Wayland is currently not possible (thanks to kinto's breaves for that insight). However, it's possible to query the gnome window manager to get this information (see https://github.com/vslobodyan/gnome-active-window). I wonder if this would be something keyd's author would be interested in seeing integrated.

Ok, that's it for now. Curious what your thoughts are and where to go from here.

[RedBearAK]

BeOS v5.0 was made freely available after the company collapsed, and there was a leak of the v5.1 "Dano" version. And the clone called Haiku is still around and being worked on. But it's hard to get BeOS to run worth a darn unless you have some compatible hardware from the era sitting around. I've never had much luck with it in VMs. It was a really unique experience while it lasted.

There are definitely a number of different remappers around. I think I stumbled on Kinto from one of his own articles on Medium.

https://benreaves.medium.com/kinto-type-on-windows-like-its-a-mac-9c52f8e29e5d

Regarding the Cmd+click issue... I'm not sure exactly what the problem is that you're referring to? I've never had a problem with Cmd+clicking on things while using Kinto. I'm always Cmd+clicking links in Firefox to open in new tabs. Maybe you're attempting to do something that I haven't tried? From what I understand, Ben had to slightly modify xkeysnail in his own fork to allow "held keys" because it initially only understood key "events" (i.e., press/release), in order to make it work for what he wanted Kinto to be able to do. I think that's mainly for the Cmd+Tabbing and Cmd+Shift+Tabbing, but should also apply to Z/X/C/V operations without releasing the Cmd key. Perhaps that's the issue you're running into? Just a wild guess.

Querying the GNOME window manager for the focused app window sounds like an interesting idea. I feel like it should be possible to do something similar in all the different window managers (Xfce, Plasma, etc.). After all, something has to know which window has focus in order to send key codes to that window. Unfortunate if that really turns out to be necessary with Wayland.

But, that's pretty much the extent of my knowledge about how things actually work in Linux behind the scenes.

I can offer some ideas, some enthusiasm, some overly-enthusiastic unworkable ideas, and a bit of beta testing feedback if/when things get further along. Kinto's current state is a good reference point for what can and should be accomplished to bring the full macOS keyboard experience to Linux. I'm jumping between a Linux laptop and a MacBook Pro constantly with very little pain.

[canadaduane]

Are you using Wayland, BTW? (I'm not, although I intend to switch at some point down the road... 6 months?)

…

On Fri, Nov 19, 2021 at 12:48 AM RedBearAK ***@***.***> wrote: BeOS v5.0 was made freely available after the company collapsed, and there was a leak of the v5.1 "Dano" version. And the clone called Haiku is still around and being worked on. But it's hard to get BeOS to run worth a darn unless you have some compatible hardware from the era sitting around. I've never had much luck with it in VMs. It was a really unique experience while it lasted. There are definitely a number of different remappers around. I think I stumbled on Kinto from one of his own articles on Medium. https://benreaves.medium.com/kinto-type-on-windows-like-its-a-mac-9c52f8e29e5d Regarding the Cmd+click issue... I'm not sure exactly what the problem is that you're referring to? I've never had a problem with Cmd+clicking on things while using Kinto. I'm always Cmd+clicking links in Firefox to open in new tabs. Maybe you're attempting to do something that I haven't tried? From what I understand, Ben had to slightly modify xkeysnail in his own fork to allow "held keys" because it initially only understood key "events" (i.e., press/release), in order to make it work for what he wanted Kinto to be able to do. I think that's mainly for the Cmd+Tabbing and Cmd+Shift+Tabbing, but should also apply to Z/X/C/V operations without releasing the Cmd key. Perhaps that's the issue you're running into? Just a wild guess. Querying the GNOME window manager for the focused app window sounds like an interesting idea. I feel like it should be possible to do something similar in all the different window managers (Xfce, Plasma, etc.). After all, something has to know which window has focus in order to send key codes to that window. Unfortunate if that really turns out to be necessary with Wayland. But, that's pretty much the extent of my knowledge about how things actually work in Linux behind the scenes. I can offer some ideas, some enthusiasm, some overly-enthusiastic unworkable ideas, and a bit of beta testing feedback if/when things get further along. Kinto's current state is a good reference point for what can and should be accomplished to bring the full macOS keyboard experience to Linux. I'm jumping between a Linux laptop and a MacBook Pro constantly with very little pain. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAABALXD66KQWURS5ZEQRDUMX6NRANCNFSM5ILGDDZA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[RedBearAK]

@canadaduane

The only time I spend in Wayland is right after installing a new Linux distro that defaults to Wayland. If I forget to immediately log out and switch to Xorg/X11, the Kinto installer reminds me. Kinto is almost always the very first thing I install.

Despite vague promises of advantages, I haven’t found myself in any circumstances where I would benefit from Wayland in its current state. Even the touchpad gestures that supposedly were implemented only for Wayland with GNOME 40 on Fedora 34 failed to work on my Acer laptop. YMMV.

[canadaduane]

Regarding the Cmd+click issue... I'm not sure exactly what the problem is that you're referring to? I've never had a problem with Cmd+clicking on things while using Kinto. I'm always Cmd+clicking links in Firefox to open in new tabs. Maybe you're attempting to do something that I haven't tried?

Perhaps Kinto figured out a way to make Cmd default to Ctrl when pressed, and then override that to Meta when needed. Right now, I do the reverse--when you press Cmd ("Alt" key on my keyboard) it defaults to a Meta key press, until you press (for example) a "C", "X", or "V" key (among others) it completes the Meta release, then sends a quick Copy/Cut/Paste key combination (which usually involves Ctrl or Shift modifier).

Thanks for the insight... I will see if switching it around is simple, because then Cmd+Click would mean Ctrl+Click and no further processing would be needed.

[RedBearAK]

@canadaduane

Yes, sorry, talking about remapped keys is always confusing. I believe the scheme for Kinto is that physical Alt becomes Right Ctrl, Super/Win becomes Alt (Option) and then Ctrl becomes Super/Win. Except in terminals where Ctrl remains Ctrl. So when I hold down physical Alt (which I now think of as the Command key) it remaps to Control_R. Works with all the Cmd+click type stuff I’ve tried, including in file managers and getting to the preferences dialog for Plank.

So at times I was able to install Kinto accidentally under Wayland, for instance in OpenSuSE, before the installer script was updated for that environment. The basic modifier key remapping worked fine, and so many Linux keyboard shortcuts are just based on the Ctrl key that several times I was confused into thinking it was all working fine. Things like Alt+T to open new tabs in a browser would work. But all of the other shortcuts that require xkeysnail identifying the WM_CLASS name of the active app would of course fail.

Something the Kinto dev has tried to do is not mess with any actual built-in shortcuts except the unavoidable disabling of the overlay-key. Your script changes the copy/paste shortcuts in GNOME Terminal, but Kinto instead just remaps a whole list of Ctrl+Whatever keys to Ctrl+Shift+Whatever to make many things work in terminals. That way if you disable or uninstall Kinto everything works as normal. You may wish to think about whether you really want to be modifying any pre-existing shortcuts.

[canadaduane]

Thanks for the background and info on mapping keys.

Something the Kinto dev has tried to do is not mess with any actual built-in shortcuts except the unavoidable disabling of the overlay-key. Your script changes the copy/paste shortcuts in GNOME Terminal, but Kinto instead just remaps a whole list of Ctrl+Whatever keys to Ctrl+Shift+Whatever to make many things work in terminals. That way if you disable or uninstall Kinto everything works as normal. You may wish to think about whether you really want to be modifying any pre-existing shortcuts.

Yes, lately I've discovered that there's a much better way to do things:

1. Linux appears to have a convention that the following keys work universally as cut/copy/paste (even in terminal):

• Cut: Shift-Del
• Copy: Ctrl-Ins
• Paste: Shift-Ins

So awareness about which app is running is unnecessary here (except in a few edge cases, apparently--urxvt is one such example).

2. I no longer think it's necessary to run Interception. I'll be switching to keyd instead.

• everything I've tested works, especially with the keyd author's latest swap function addition which enables Cmd+Tab and Cmd+` functionality.

[canadaduane]

Ok, back on topic:

• how do you suggest we detect which modifier key is left of spacebar? Python script?

[RedBearAK]

@canadaduane

Yeah, I don't know much about things on that end. The Kinto GUI app is written in Python and is responsible for asking the user to press the 2nd key to the left of the spacebar, if there is no kinto.py config file yet. So that would be the Super/Win key on a PC keyboard, or Alt/Option on an Apple keyboard. Not sure which key code it would be on a Chromebook or IBM non-Windows keyboard.

It's here if you want to take a look at the app:

https://github.com/rbreaves/kinto/blob/aa53c83c616410b30addae0d9fe9acfa30b98a63/linux/gui/kinto-gui.py#L1282