How to unset Overlay (Super) key on my DE in order to proceed with Kinto in Lubuntu?

[pligor]

Practically the question is described here: https://askubuntu.com/questions/1423683/how-to-unset-overlay-super-key-on-my-de-in-order-to-proceed-with-kinto-in-lubu

Copy pasting here the contents of the question:

Note that solution with gsettings recommended here does not seem to apply in Lubuntu: How do I disable the Super key?

Kinto https://github.com/rbreaves/kinto is asking me to press the Super-Key but it will not be triggered in the app as it will open the applications in the taskbar

Therefore the solution is not to completely disable the Super Key as this is meant to be used and also need to be recorded by Kinto. Only need to disable its global effect

More specifically we are stuck in the Kinto setup screen where you have the prompt:

Identifying your Keyboard...

Press the 2nd key Left of the spacebar.

if stuck here then unset Overlay (Super) key on your DE Obviously the 2nd key left to my keyboard is the Super-Key (aka Windows-Key)

Any ideas how to do so ?

[pligor]

Managed to find this out but unfortunately Kinto is not suitable for developers

[rbreaves]

Managed to find this out but unfortunately Kinto is not suitable for developers

I have not yet worked w/ the LXDE DE w/ Kinto, so I would need to some testing and find the programmatic way of disabling the Overlay key for that DE. I would be happy to accept any PR request as well that fixes it, but any CLI command posted in this thread would be enough for me to integrate the fix.

I would also want to test it on a Lubuntu VM just to make sure the install script goes all the way through.

Other than Kinto not working for you out-of-the-box, I am not sure what your comment is referencing when you say Kinto is not suitable for developers? I clearly have quite a few developers and users using Kinto daily, and I dog food it pretty relentlessly on both Linux distros and Windows.

[pligor]

Hi ! If you check the stackoverflow thread you will find out a comment of how to configure this via gui. Not sure of any command lines yet. What I referred to regarding developers, I meant in general power users who happen to also develop and to need to have to change languages in the keyboard. Anyway I might not have concrete examples right now but unfortunately in the range of programs that I am using (terminal, native gui programs, java apps, text editors, etc.) I understand that these are too many kind of use cases to have a mac-like experience in all of them. My muscle memory from mac if failing often when using linux. In some apps the expected shortcuts do not work, for example for copy and paste or worse it could be blocked. Anyway I really appreciate the great work in this repository but you might be trying to solve a problem which is too large/too complex and the communities (mac community and linux community) to do not want to consolidate

[rbreaves]

If you don't mind posting the list of editors and apps you use then I do not mind putting those things on a list to look at.

Some manual work does have to be done for some editors that are Electron based - such as VSCode - which I apparently have not documented very well but that is because I remap to using Sublime Text 3 remaps on VSCode any ways.. something I went ahead and created a quick gist for just now. https://gist.github.com/rbreaves/b3e195a627907df36e22ec0e65012c68

If you want the specific macOS remaps in VSCode w/ the original VSCode keymap set then you will have to manually fix some of the keybindings in the app due to VSCode being an electron based app, it has issues with the Alt key specifically that can't be easily be overcome.

If you would like to share the specific terminals, gui apps, java or text editors then I am sure I and possibly others here can help add them to be part of Kinto for anything the keymapper may have possibly missed. It is pretty dynamic though and Terminal coverage tends to be insanely good on Linux, but even Windows too w/ Windows Terminal especially.

This app does have a leaning towards developer usage though - as I am a developer and one that appreciates things just working like they often do in the Apple world. Developer apps are often pretty hotkey heavy - so it makes sense getting it to full coverage for every app or IDE a developer may use can be difficult depending on the creator of said software. Short of Adobe most companies do not prize consistency of their hotkeys or they use hotkeys that will be trampled on across OS's - forcing them to use different sets of hotkeys - which Kinto actually does account for in some apps and does so better than their original creator - such as jetbrains. Kinto does a better job of remapping JetBrains default hotkeys on Linux and Windows to macOS than what Jetbrains does with their official OSX remap config because they have to avoid colliding with OS level hotkeys.

Kinto literally remaps OS level hotkeys to help get them out of the way and allow for remapping to hotkeys that would normally not be possible to remap to at all or w/ a lot more effort that many people would not go through the hassle of doing.. and mind you I do a lot of this with the concept and idea that you can still suspend the app and get back all of your default hotkeys in an instant. (although I do keep the overlay key removed on Linux, I could fix that in a later release though)

All in all I do not think you will find a better remapping tool that does this and certainly not with the same level of coverage. But if you ever do feel like posting a list of applications you would like to see better supported then I will try to accommodate that or guide you in the process of adding it to Kinto where the readme may have failed you.

It is true though that I am not familiar with changing out the keyboard language away from english so if things fail in other languages then that is a harder thing for me to really dog food - but again I accept PRs for anything that will improve this app and additional language support would be on that list, although I would recommend those improvement to be upstreamed directly to xkeysnail and its new fork keyszer.

[joshgoebel]

Language swaps are always going to be problematic because you're literally changing the meaning of the keys - and all we see (in the mapper) are US keycodes... minimally (I think) one would need to build language support into the remapper and then have a way for the DE to communicate the language change to the keymapper. Honestly it's still unclear to me exactly what happens when one changes language - and which problems crop up - so its possible it's simpler than I'm thinking.

Definitely open to talking with anyone who'd want to work on that. I feel like we need a multi-language champion who really cares about the problem, knows Python, and has the time to invest.

[rbreaves]

Tbh I hadn't wondered too much till just now.. how do you even copy and paste in other languages? Is it located in the same location as US keyboards or does it follow some logical thing in that specific language?

[RedBearAK]

Tbh I hadn't wondered too much till just now.. how do you even copy and paste in other languages? Is it located in the same location as US keyboards or does it follow some logical thing in that specific language?

@rbreaves

According to my testing with an AZERTY Apple USB keyboard, when evdev is not involved and you change the keyboard layout in your DE, the shortcuts move to the new location of the key in that layout. Like Cmd+A to select all uses what was the “Q” key position in QWERTY. Same thing happens in Linux and macOS. I didn’t test on Windows but I assume it works the same way. And you can test this even if you don’t have a physical non-US labeled keyboard. Just change your keyboard layout on any keyboard and use the software keyboard viewer to see how the keys changed. Your standard US keyboard will behave exactly the same way as a “real” international keyboard. The only difference is what gets printed on the keys. Well, almost. There’s one additional physical key on the AZERTY. It’s in the key definition file as “KEY_102ND”.

(I don’t know what happens when you move to a language that doesn’t even use a similar alphabet. One wonders where the shortcuts are logically placed on CJK keyboards.)

But when evdev is involved, it just sees the same US key codes as before. It needs a way to notice the layout change and an alternate key definition file for each language. Or it will never work very well with non-US layouts. This is a problem not just with shortcuts but with macros and anything else processing strings into typed keys. The output ends up wrong if you switch layouts. The key mapper doesn’t know that typing Shift-Q will now output “A” because you switched to AZERTY, but X11 does. So everything goes off the rails.

On the other hand this could be argued to be a feature rather than a bug. It lets shortcuts stay at the same physical locations even when you switch layouts. How advantageous this could be would depend on how frequently the user needs to switch layouts. Some users have to deal with multiple languages and actually do a lot of input switching.