Clarity on problems with KDE Window Switching

[jonchun]

You mention here that there are issues with getting KDE alt+tabbing to work like it does on macOS.

However, that has not been my experience at all on KDE Neon. Here is a screenshot of my settings for the Task Switcher. (In the Alternative tab, I also have Ctrl+Shift+Tab set). I'm guessing that with your black magic, you can probably remap my Ctrl+Tab and Ctrl+Shift+tab to Ctrl+F11 or something similar to in Gnome so that I don't have to set up 2 hotkeys for the same thing.

This works nearly exactly like it does on macOS for me so I'm happy with it, but I'm opening this for further clarity on what issues you've had so that I can either start thinking of a workaround or considering whether or not I will personally run into it in the future. I'm sure that it might help others in the future who are trying to decide between using kinto with KDE vs Gnome as well.

[rbreaves]

It works as long as Ctrl is combined to use the most normally used keys, but I am specifically wanting to use keys outside the typical keyboard layout aka F13, F14 so that I can more or less know that I won't be interfering with a users existing or custom hot keys.

I believe I can have it work if I remap Ctrl+Tab -> Ctrl+` as an example.. but I also kinda want to double check that. I think that did work. To simplify things, as far as maintainability goes though, I am always trying to find a singular solution that works across the most DE's so I don't have a lot of one off fixes for each DE. I want to minimize my technical debt in that sense as much as I can, the less logic I need to add the better.

Gnome and XFCE supports that configuration very well, but KDE under manjaro has not supported that same configuration well.

XKB is also able to re-route Ctrl+Tab -> Ctrl+F14 just fine while routing (physical ctrl key) Super+Tab back to Ctrl+Tab without it re-routing to Ctrl+F14 just fine due to its multi-level features. I can try this out again, but last I tested under Manjaro KDE the OS saw the key presses and the remap but the KDE Task Switcher just ignored it outright.

[rbreaves]

Well that is bad.. the dev branch does crash KDE Neon in VM for me just as it did for you I guess o.o.

[jonchun]

Yea. I couldn't get the dev branch to work at all. It just poops out. I think for now I'm pretty happy with where I'm at. I've been running into this insane screen tearing once in a while that fixes itself on reboot, but I find it highly unlikely that it has anything to do with kinto. (although it is certainly the one app that I've been testing the most)

[rbreaves]

Hmmmm.. yea I probably can't help with the screen tearing and kinto shouldn't impact anything like that. I know galliumOS uses xfce and combines it with compton to help lessen screen tearing issues. Don't know if you can look into setting up compton for KDE Plasma 5 or not to address screen tearing.

[rbreaves]

Well in a bizarre twist after having like 3 system level crashes on my dev branch it is like it worked itself out on its own. It is running without issue on the 4th reboot. I don't really know what went wrong.. I just kept re-installing from the setup.py, especially after seeing my user_config.json file had gone completely blank on one of the reboots..

It was reproducible up until now, so I don't know what the issue actually was.

[rbreaves]

Well I am reproducing it reliably now lol. Not sure what the issue is, but every time I come back the moment I go from term to gui the system crashes on dev. Pretty bad bug for something that only happens on KDE Neon.

Ok, finally figured out why dev all of a sudden started bugging out.. apparently KDE Neon does not like it.. IF the run commands for gui and term do not include the "setxkbmp -option" first. Other distros don't seem to care, but KDE Neon does - but it also means that the Konsole input bug can appear. What I may try is running "setxkbmap -option" but append "sleep 0.1" or 0.2 to it as well and see if I can get away with that.

Also this instability only occurs if the service starts while Konsole has the focus.. if any GUI app has the focus first then the crash will not occur and having setxkbmap in the run command is not needed. Truly bizarre imo.

[rbreaves]

I will look into this more tomorrow, my theory about setxkbmap was mostly right, but that is not a real solution to the problem.

I believe it is more likely an issue with the specific xkbcomp version KDE Neon uses and that the mac.term symbols file, if applied first, and then the mac.gui file in dev is applied after is the primary culprit. It is where the real differences are between master and dev. I suspect the keymaps in that file - if applied in that order is what creates the actual instability. Setxkbmap covers it up though because it resets things back to normal before applying the keymaps.

I am going to fix dev in one of two ways, either force the GUI keymap to always apply first, even if the term will need to be set first on boot, but I may also step through the dev keymaps more carefully to find what could be causing this issue.

[jonchun]

This is amazing stuff! Fingers crossed that the features in dev make it to master. I would love to have cmd+tabbing built in. I'm in the process of porting my autoinstall script to run on KDE neon and it is turning out amazing. My end goal is to have a low-configuration installer that asks maybe just a few questions, and after a few minutes transform KDE neon into what could pass as a customized macbook. Unfortunately, since I chose KDE neon for this, I couldn't use the dev branch for all the cool new remappings :(

---

I really wanted my screenshot features working right so I poked around in the xkb files a bit and noticed that you seem to have screenshot stuff commented out. Is that broken?

Edit: Looks like it is int mac_term but not in mac_gui. Don't understand this stuff well enough to be able to tell if this is intentional.

[rbreaves]

@Jonchun I honestly don't recall why I commented out the screenshot stuff exactly. It was probably built out for one specific DE, but not all 3 and at the time of writing it I did not have a good method worked out for managing different shortcut keys. I do now though via perl and regex in the setup file, which can quickly uncomment out the DE specific chunks of code I want enabled.

I just need to revisit it and make sure I align things with the default hotkeys for the 3 major DE's I am supporting.

I am going to close this ticket for now since the KDE Window switching has more or less been added, even if not perfected. If you come up with a better way then just comment on whichever thread you want and I will take another look at it then and get it merged.

[jonchun]

Spent a good hour or so on trying to fix this for myself this morning but no luck. Mostly because the xkb keymap files are so hard to work with.

Some things I've noticed.

1. It seems that the KDE instability I was experiencing is still happening. (KDE neon 5.18) Nothing in the logs but my entire DE is just crashing and going black like before, forcing me to SSH in to fix it. (For some reason I couldn't bring up my other consoles with ctrl+alt+f2 but i might have just been doing it wrong because I didn't try too hard) It doesn't happen 100% of the time, but when it does, I haven't found a way to recover it easily.
2. I've reverted to 9a451bd93c962f39968df07998bb52a71ff8794a which is when things were working decently for me, and will likely stay here for now given the instability/reverse cycling from terminal on the current master branch.
3. On commit 9a451bd93c962f39968df07998bb52a71ff8794a, I'm able to get terminal to forward cycle by simply binding "ctrl+tab" to the task switcher and "ctrl+shift+tab" to the alternate task switcher hotkey. However, this does seem to come with the downside of not being able to use shift to switch backwards.
   • Note: Pressing cmd+tab while in terminal doesn't immediately bring up the task switcher the way it does from a GUI app, which I thought was strange... i need to tab it a few times before it'll show. (i was experiencing the same thing even on the latest dev branch with the mapping to ctrl+shift+f14/13). After testing out the behavior a bit, I'm pretty sure what's happening when I start cmd+tabbing from a terminal application and hitting tab until the task switcher shows up, is that somehow the task switcher is switching me back from terminal to my most recently used GUI window, and then triggering the normal task switcher hotkey at which point the task switcher window pops up.
   • Is there any way to clear the shift modifier for ctrl+tab only when using the terminal keybinds? I think I asked you this already so I can go digging around for it, but we've worked through so many issues already it might just be faster to ask you once more.

Other than that, since I reverted quite far, it seems the firefox gui issue is back so I'll probably look into cherrypicking that for myself after work. nvm it looks like this was just some weirdness in not fully restarting firefox. it looks like the commit i'm on does include the firefox fixes so I'm good on that front.

[rbreaves]

@Jonchun that’s surprising.. for the life of me I could not replicate an unexpected OS fault/crash once I changed the group for the down key on the mac_gui symbols file. It was certainly that segment of code that created the instability.

I’ll retest it & yea - there’s not much chance that I’ll find keeping the mapping on a default of ctrl+tab as acceptable since that would just kill the in-app tab switching.

Trying to think though.. maybe if I could trigger an unmapping of ctrl+tab of the task switcher the moment Super is held. Not sure how that’d work while using the terminal though, perhaps try only binding ctrl+shift+tab.. not sure.

[jonchun]

that would just kill the in-app tab switching.

That's a fair point. Is there any way to simply remap "cmd+tab" back to "alt+tab" instead of "ctrl+tab" or "ctrl+shift+tab"?

I think the weirdest/most annoying behavior is whatever is causing the task switcher to not show up properly when trying to start tabbing from a terminal window. Perhaps you're right and it's just going to be broken, so the best option is to just have it reverse cycle when starting it from a terminal window. (assuming we want reverse cycling to work)

[jonchun]

Quick update before i need to stop working on this for now. I think you might be able to overwrite "meta+tab" and perhaps change around the activities switching hotkeys.

The reason I say this is because I tried binding it to "meta" with keyswap off just to see if I can even correctly bind it to modifiers that are not "alt". However, when I logged out and back in (I've noticed something similar to you where changes to task switcher seem to not take without a logout), Pressing the real "meta" button + tab will bring up the task switcher window even though keyswap service is ON, meaning "meta" is mapping to "alt". I think maybe meta is being treated specially? haven't had a chance to play too much.

[rbreaves]

@Jonchun If I am understanding you correctly that may make some sense. Why I appear to have difficulty mapping keybinds in the UI after doing the xkbcomp keymap changes. I think the KDE apps are listening to the udev layer and the xkb layer at the sametime and it gets confused.

What makes it even more confusing is that when Firefox has the focus it appears to not see the xkb remap of Ctrl+Shift+F13 or F14 properly.. but then every other GUI app appears to work fine. I am to the point of wanting to find a different 3rd party alt tab switcher.

[rbreaves]

@Jonchun I understand what is occurring now because I just attempted to use a script instead while in the terminal to cycle windows.. wmctrl with python and xbindkeys and what occurred was very interesting. So the moment the window switching begins to happen the keymap changes because the Window focus change occurs. I did not think that was occurring but it is before the new Window ever takes full focus.

That is why it has such an unexpected behavior. It is still strange in that even when the hotkeys are aligned between the terminal and gui apps the reverse cycling occurs. I cannot really explain that.

Maybe the appropriate fix is to update kintox11 to ignore XNextEvents while any keyboard keys are being held down. Maybe not ignore it, but at least block the keymap refresh until the keyboard key is released. I think if Kintox11 did that it could actually fix the Cmd+Tab issue.

XEvent wise it will probably look like KeyPress, KeyPress, KeyReleased, ConfigureNotify (window change), KeyPress, KeyReleased, ConfigureNotify, KeyReleased.

I will need to keep track of the KeyPress total vs KeyReleased total and only continue when they match.

C++ reference for either building out the C equivalent or may want to convert kinto over to c++. https://stackoverflow.com/questions/22749444/listening-to-keyboard-events-without-consuming-them-in-x11-keyboard-hooking

Shows an example of grabbing even hotkeys, something x11 normally does not expose while another program has grabbed the keys.

[rbreaves]

@Jonchun I am making some progress and in fact I think this will lead to some definite improvements in another area as well, but the pulling in the keypresses from gdk/gtk apps is being a little problematic with the basic x11 code I have found to help with this. I can get keypresses from konsole, but not gnome-terminal, sublime or firefox atm. Once I can reliably get the keypresses globally I will be looking to update dev and master with the new ability.

On some level though I don't want to implement this, because it breaks one of the primary goals of the keymapper which is to do its work without monitoring key input. However it appears this is a scenario where monitoring input is the only way to avoid a premature keyswap that will cause issues if it is allowed.

All in all though it is a compromise that doesn't impact its overall speed and efficiency, which is to say normal individual key presses for input is not being remapped by kinto itself but rather system level/builtin programs are still doing that work.

[jonchun]

That's amazing news!

My thoughts on:

breaks one of the primary goals of the keymapper which is to do its work without monitoring key input.

All in all though it is a compromise that doesn't impact its overall speed and efficiency,

I can't speak for everyone else out there, but I'd venture a guess and say that for most people using this, they'd agree with me in saying that as long as the overall performance impact is negligible or nonexistent, we don't care HOW the effects are achieved... just that they are 😂

On a side note, is there an easy/simple way to tell whether an app is a GTK app/qt/etc? Especially because of my theming, it can be hard to tell and it's not always immediately obvious from a google of the app itself.

[rbreaves]

On a side note, is there an easy/simple way to tell whether an app is a GTK app/qt/etc? Especially because of my theming, it can be hard to tell and it's not always immediately obvious from a google of the app itself.

I am honestly not sure and will be finding that out. Of course it will be a C implementation of detecting the type. Right now I am reading notes on stackoverflow, there may be other ways of grabbing the input as well that could be more reliable still.

https://stackoverflow.com/questions/11315001/x-keypress-release-events-capturing-irrespective-of-window-in-focus

As one of the commenters suggests it is best to not monitor the entire keyboard and instead grab the specific key or combo you are after.

This is a good example but when I try to modify it for Super only it seems to not pick up at all and to be honest since this uses udev over xkb I will need to bind to either alt or super depending. https://gist.github.com/skx/f4ab600fb6ceb48099af

[rbreaves]

@Jonchun So after going through several different possible solutions I am finding this is to be fairly difficult. KDE and many apps in linux will grab a key combo for itself and prevent other apps from doing so as well, so grabbing the combo is out.

For now I have resolved it in the dev branch though if you want to try the latest.. what I ended up doing was tweaking the mac_term symbols file so that it would properly release the Control_L key - that was my fault, it should have been already. The only issue that remains is that I can't also properly release the Shift key as needed, but you can easily press the shift or enter key after having used the Cmd+Tab while in the Terminal and that will release the App Switcher..

It is slightly annoying to have this bug like that, but it is at least functional for now (and does not impact its functionality under Gnome, it still works as expected and hopefully under xfce too).

Update: this interpret thing looks promising depending on how flexible it may be. https://askubuntu.com/questions/1042385/using-xkb-to-map-a-key-combination-to-another

[jonchun]

I'll give it a shot soonTM. Been wrapped up with work and not sure when I'll have a chance to play with this stuff :(

Will update with feedback.

[rbreaves]

Another option is to literally remove the binding of Shift via SetMods for the terminal.. and then just manually create all of the keys which should bind Ctrl + Key with Ctrl + Shift + Key. That really is a simple solution as well. Although probably made more complicated as you take into account all the different languages you'd want to support and make sure you're not breaking in some bizarre way.

It would be the less ideal to handle it, a brute force approach. It would work, but at what cost sort of thing lol. Surely we can find something more elegant.

[jonchun]

Another option is to literally remove the binding of Shift via SetMods for the terminal.. and then just manually create all of the keys which should bind Ctrl + Key with Ctrl + Shift + Key. That really is a simple solution as well. Although probably made more complicated as you take into account all the different languages you'd want to support and make sure you're not breaking in some bizarre way.

It would be the less ideal to handle it, a brute force approach. It would work, but at what cost sort of thing lol. Surely we can find something more elegant.

Perhaps it can be an advanced option? I don't know about you, but I might actually PREFER that because I've noticed sometimes my ctrl+c doesn't work the way I expect it to when kinto is enabled. (I expect it to send an interrupt) but it instead just prints some weird characters. I also personally only really use cmd+c, cmd+v, cmd++, cmd+- in a terminal setting. (maybe you can fill me in here on what other cmd+___ hotkeys are useful in the terminal). No idea how to solve the language/keyboard type issue though.

I haven't reported the ctrl+c stuff because I haven't had a chance to write up/investigate the behavior yet, but I might as well bring it up since your "bruteforce" idea would almost definitely solve my issue.

[rbreaves]

@Jonchun I've been playing with xkeysnail today.. and since it is essentially a python based wrapper for a udev implementation of the keyswap that kinto is doing - I might actually retire kintox11 tomorrow or over the next few days and simply replace it with xkeysnail and a single config file that will work across all keyboards, OS's and DE's.

It looks like I have found a way to avoid the shift issue altogether because well udev allows me remap the left and right control keys easily and as such I can remap either to use shift or not and it will abide by those rules easily enough. I can also keep it far less verbose while doing the same amount of work that xkb does.

It will also be more compatible with even more applications and I think have less unexpected behavior.

Edit: The one thing it can't do is a caret check for the input field unless I fork and update xkeysnail to support checking the caret status. That could throw a minor wordwise wrench in things for chrome and firefox.

[rbreaves]

@Jonchun I guess you can kinda ignore this comment.. because once I tried testing it under KDE it is kinda clear that the key combo is not transmuted in a way to keep the control key held down. Xkeysnail I think captures the combo and then immediately sends a simple combo in its place, but it won't keep ctrl held persistently.

So xkeysnail sorta works under XFCE on my chromebook for app switching, but it does start to break after several app swaps and I am not sure if that is a fault of XFCE or xkeysnail. I am about to test this under a KDE VM as well and see what happens, but I am nervous that xkeysnail could be inconsistent in remapping properly in which case this might not be as viable as I had hoped.

It is also apparent that xkeysnail and xkb remapping at the same time is a bad idea, so if you try this script out you will need to stop kinto first.

sudo xkeysnail test.py

# -*- coding: utf-8 -*-

import re
from xkeysnail.transform import *

# [Global modemap] Change modifier keys as in xmodmap
define_conditional_modmap(lambda wm_class: wm_class not in ("Gnome-terminal","konsole","io.elementary.terminal","terminator","sakura","guake","tilda","xterm","eterm","kitty"),{
    # # Chromebook
    # Key.LEFT_ALT: Key.RIGHT_CTRL,   # Chromebook
    # Key.LEFT_CTRL: Key.LEFT_ALT,    # Chromebook
    # Key.RIGHT_ALT: Key.RIGHT_CTRL,  # Chromebook
    # Key.RIGHT_CTRL: Key.RIGHT_ALT,  # Chromebook

    # Default Mac/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
    Key.RIGHT_META: Key.RIGHT_ALT,  # WinMac
    Key.RIGHT_CTRL: Key.RIGHT_META, # WinMac

    # # Mac Only
    # Key.LEFT_META: Key.RIGHT_CTRL,  # Mac
    # Key.LEFT_CTRL: Key.LEFT_META,   # Mac
    # Key.RIGHT_META: Key.RIGHT_CTRL, # Mac
    # Key.RIGHT_CTRL: Key.RIGHT_META, # Mac
})

# [Conditional modmap] Change modifier keys in certain applications
define_conditional_modmap(re.compile("Gnome-terminal|konsole|io.elementary.terminal|terminator|sakura|guake|tilda|xterm|eterm|kitty"), {
    # # Chromebook
    # Key.LEFT_ALT: Key.RIGHT_CTRL,
    # # Left Ctrl Stays Left Ctrl
    # Key.LEFT_META: Key.LEFT_ALT,
    # Key.RIGHT_ALT: Key.RIGHT_CTRL,
    # Key.RIGHT_CTRL: Key.RIGHT_ALT,
    # # Right Meta does not exist on chromebooks

    # Default Mac/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
    Key.RIGHT_META: Key.RIGHT_ALT,  # WinMac
    Key.RIGHT_CTRL: Key.LEFT_CTRL, # WinMac

    # # Mac Only
    # Key.LEFT_META: Key.RIGHT_CTRL,  # Mac
    # Left Ctrl Stays Left Ctrl
    # Key.RIGHT_META: Key.RIGHT_CTRL, # Mac
    # Key.RIGHT_CTRL: Key.LEFT_CTRL, # Mac
})

# Keybindings for Sublime Text
# re.compile("Sublime_text")
define_keymap(re.compile("Sublime_text"),{
    # Select All Matches
    K("M-C-g"): K("M-REFRESH"),
}, "Sublime Text")

define_keymap(None,{
    # Cmd Tab - App Switching Default
    K("RC-Tab"): K("C-f13"),
    K("RC-Shift-Tab"): K("C-Shift-f14"),
    # In-App Tab Switching
    # K("M-Tab"): K("C-Tab"), # Chromebook
    # K("M-Shift-Tab"): K("C-Shift-Tab"), # Chromebook
    K("Super-Tab"): K("C-Tab"), # Default
    K("Super-Shift-Tab"): K("C-Shift-Tab"), # Default
})

define_keymap(re.compile("Gnome-terminal|io.elementary.terminal|terminator|sakura|guake|tilda|xterm|eterm|kitty"),{
    # Ctrl Tab - In App Tab Switching
    # LC is already set
    K("LC-Grave") : K("LC-Shift-Tab"),
}, "Terminals tab switching")

define_keymap(re.compile("konsole"),{
    # Ctrl Tab - In App Tab Switching
    K("LC-Tab") : K("Shift-Right"),
    K("LC-Shift-Tab") : K("Shift-Left"),
    K("LC-Grave") : K("Shift-Left"),
}, "Konsole tab switching")

define_keymap(re.compile("Gnome-terminal|konsole|io.elementary.terminal|terminator|sakura|guake|tilda|xterm|eterm|kitty"),{
    # Converts Cmd to use Ctrl-Shift
    K("RC-V"): K("C-Shift-V"),
    K("RC-MINUS"): K("C-Shift-MINUS"),
    K("RC-EQUAL"): K("C-Shift-EQUAL"),
    K("RC-BACKSPACE"): K("C-Shift-BACKSPACE"),
    K("RC-Q"): K("C-Shift-Q"),
    K("RC-W"): K("C-Shift-W"),
    K("RC-E"): K("C-Shift-E"),
    K("RC-R"): K("C-Shift-R"),
    K("RC-T"): K("C-Shift-t"),
    K("RC-Y"): K("C-Shift-Y"),
    K("RC-U"): K("C-Shift-U"),
    K("RC-I"): K("C-Shift-I"),
    K("RC-O"): K("C-Shift-O"),
    K("RC-P"): K("C-Shift-P"),
    K("RC-LEFT_BRACE"): K("C-Shift-LEFT_BRACE"),
    K("RC-RIGHT_BRACE"): K("C-Shift-RIGHT_BRACE"),
    K("RC-A"): K("C-Shift-A"),
    K("RC-S"): K("C-Shift-S"),
    K("RC-D"): K("C-Shift-D"),
    K("RC-F"): K("C-Shift-F"),
    K("RC-G"): K("C-Shift-G"),
    K("RC-H"): K("C-Shift-H"),
    K("RC-J"): K("C-Shift-J"),
    K("RC-K"): K("C-Shift-K"),
    K("RC-L"): K("C-Shift-L"),
    K("RC-SEMICOLON"): K("C-Shift-SEMICOLON"),
    K("RC-APOSTROPHE"): K("C-Shift-APOSTROPHE"),
    K("RC-GRAVE"): K("C-Shift-GRAVE"),
    K("RC-BACKSLASH"): K("C-Shift-BACKSLASH"),
    K("RC-Z"): K("C-Shift-Z"),
    K("RC-X"): K("C-Shift-X"),
    K("RC-C"): K("C-Shift-C"),
    K("RC-V"): K("C-Shift-V"),
    K("RC-B"): K("C-Shift-B"),
    K("RC-N"): K("C-Shift-N"),
    K("RC-M"): K("C-Shift-M"),
    K("RC-COMMA"): K("C-Shift-COMMA"),
    K("RC-DOT"): K("C-Shift-DOT"),
    K("RC-SLASH"): K("C-Shift-SLASH"),
    K("RC-KPASTERISK"): K("C-Shift-KPASTERISK"),
}, "terminals")

# define_keymap(re.compile("Chromium-browser"),{
#     # K("RC-Tab"): K("C-f2"),
#     # K("RC-Shift-Tab"): K("C-f1"),
# }, "Chromium-browser")

[rbreaves]

@Jonchun Holy hell.. did I finally figure this shit out. So KDE definitely does not like it when you remap that Tab key AT ALL. The key is to actually remap it on the evdev/udev level before you even begin. So your Tab key will literally be F13 - and will only map back to Tab when using any GUI app or Terminal - BUT if you press the Cmd key (which is Control_R - even though it is on the left) then F13 stays F13 with and without Shift.

It also means that if the xkeysnail or kinto service stops running.. you will be left without a Tab key :/.. although once converted to a systemd service it could actually be undone in your user session w/o logging on and off with a standard "systemctl --user stop whatever". Systemd allows for a script to clean things up on a proper stop of the service. Undoing your Task Switcher keybind could also be done - but would probably be unreliable until you log off and back on.

So I will need to try and fully script this so you or anyone can apply the proper fix, but here's what my KDE VM looks like now.

Note: Your evdev:input values will differ from mine. Followed this guide.

Get your evdev info via this command

cat /proc/bus/input/devices | awk '/eyboard/{for(i=2;i<=x;)print a[i++];print}{for(i=1;i<x;i++)a[i]=a[i+1];a[x]=$0;}' x=2

evdev:input:bvpe-

Get your Tab value via

sudo evtest /dev/input/event`cat /proc/bus/input/devices |rep -A2 keyboard | tail -n1 | awk '{print substr($0,length($0),1)}'`
or
sudo evtest /dev/input/event{number}

type 4 (EV_MSC), code 4 (MSC_SCAN), value 0f
type 1 (EV_KEY), code 15 (KEY_TAB), value 1

In my case Tab = 0f

1. sudo vim /etc/udev/hwdb.d/99-keyboard.hwdb

   evdev:input:b0011v0001p0001*
   KEYBOARD_KEY_0f=f13

2. Then run these commands

   sudo systemd-hwdb update
   sudo udevadm trigger

After all that I log out, and log back in, this is important Task Switcher will only fully respect these changes on a log off and back on. After that I stop the keyswap (kinto) service and open the Task Switcher and set the new Cmd+Tab combo (which registers as Ctrl+Tools & Ctrl+Shift+Tools).

Then I run my xkeysnail script instead. At this point though I could update the xkb and kintox11 method to make use of the new F13 key and remap it just as well.. but honestly I like using xkeysnail and remapping F13 to be Tab in most conditions, and simply remapping it back to F13. Only thing xkeysnail really lacks is the caret input detection until I can get around to understanding it well enough to add that in.

sudo xkeysnail ./kinto.py

kinto.py

# -*- coding: utf-8 -*-

import re
from xkeysnail.transform import *

# [Global modemap] Change modifier keys as in xmodmap
define_conditional_modmap(lambda wm_class: wm_class not in ("Gnome-terminal","konsole","io.elementary.terminal","terminator","sakura","guake","tilda","xterm","eterm","kitty"),{
    # # Chromebook
    # Key.LEFT_ALT: Key.RIGHT_CTRL,   # Chromebook
    # Key.LEFT_CTRL: Key.LEFT_ALT,    # Chromebook
    # Key.RIGHT_ALT: Key.RIGHT_CTRL,  # Chromebook
    # Key.RIGHT_CTRL: Key.RIGHT_ALT,  # Chromebook

    # Default Mac/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
    Key.RIGHT_META: Key.RIGHT_ALT,  # WinMac
    Key.RIGHT_CTRL: Key.RIGHT_META, # WinMac

    # # Mac Only
    # Key.F13: Key.TAB,
    # Key.LEFT_META: Key.RIGHT_CTRL,  # Mac
    # Key.LEFT_CTRL: Key.LEFT_META,   # Mac
    # Key.RIGHT_META: Key.RIGHT_CTRL, # Mac
    # Key.RIGHT_CTRL: Key.RIGHT_META, # Mac
})

# [Conditional modmap] Change modifier keys in certain applications
define_conditional_modmap(re.compile("Gnome-terminal|konsole|io.elementary.terminal|terminator|sakura|guake|tilda|xterm|eterm|kitty"), {
    # # Chromebook
    # Key.LEFT_ALT: Key.RIGHT_CTRL,
    # # Left Ctrl Stays Left Ctrl
    # Key.LEFT_META: Key.LEFT_ALT,
    # Key.RIGHT_ALT: Key.RIGHT_CTRL,
    # Key.RIGHT_CTRL: Key.RIGHT_ALT,
    # # Right Meta does not exist on chromebooks

    # Default Mac/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
    Key.RIGHT_META: Key.RIGHT_ALT,  # WinMac
    Key.RIGHT_CTRL: Key.LEFT_CTRL, # WinMac

    # # Mac Only
    # Key.F13: Key.TAB,
    # Key.LEFT_META: Key.RIGHT_CTRL,  # Mac
    # # Left Ctrl Stays Left Ctrl
    # Key.RIGHT_META: Key.RIGHT_CTRL, # Mac
    # Key.RIGHT_CTRL: Key.LEFT_CTRL, # Mac
})

# Keybindings for Sublime Text
# re.compile("Sublime_text")
define_keymap(re.compile("Sublime_text"),{
    # Select All Matches
    K("M-C-g"): K("M-REFRESH"),
}, "Sublime Text")

define_keymap(None,{
    K("RC-Tab"): K("RC-F13"),
    K("RC-Shift-Tab"): K("RC-Shift-F13"), 
    # Cmd Tab - App Switching Default
    # K("RC"): pass_through_key,
    # K("RC-Tab"): K("C-F13"),
    # K("RC-Shift-Tab"): K("C-f1"),
    # In-App Tab switching
    # K("M-Tab"): K("C-Tab"), # Chromebook
    # K("M-Shift-Tab"): K("C-Shift-Tab"), # Chromebook
    K("Super-Tab"): K("C-Tab"), # Default
    K("Super-Shift-Tab"): K("C-Shift-Tab"), # Default

})

define_keymap(re.compile("Gnome-terminal|io.elementary.terminal|terminator|sakura|guake|tilda|xterm|eterm|kitty"),{
    # Ctrl Tab - In App Tab Switching
    # LC is already set
    K("LC-Grave") : K("LC-Shift-Tab"),
}, "Terminals tab switching")

define_keymap(re.compile("konsole"),{
    # Ctrl Tab - In App Tab Switching
    # K("LC-Tab") : K("Shift-Right"),
    # K("LC-Shift-Tab") : K("Shift-Left"),
    K("LC-Grave") : K("Shift-Left"),

}, "Konsole tab switching")

define_keymap(re.compile("Gnome-terminal|konsole|io.elementary.terminal|terminator|sakura|guake|tilda|xterm|eterm|kitty"),{
    # Converts Cmd to use Ctrl-Shift
    K("RC-Tab"): K("RC-F13"),
    K("RC-Shift-Tab"): K("RC-Shift-F13"),
    K("RC-V"): K("C-Shift-V"),
    K("RC-MINUS"): K("C-Shift-MINUS"),
    K("RC-EQUAL"): K("C-Shift-EQUAL"),
    K("RC-BACKSPACE"): K("C-Shift-BACKSPACE"),
    K("RC-Q"): K("C-Shift-Q"),
    K("RC-W"): K("C-Shift-W"),
    K("RC-E"): K("C-Shift-E"),
    K("RC-R"): K("C-Shift-R"),
    K("RC-T"): K("C-Shift-t"),
    K("RC-Y"): K("C-Shift-Y"),
    K("RC-U"): K("C-Shift-U"),
    K("RC-I"): K("C-Shift-I"),
    K("RC-O"): K("C-Shift-O"),
    K("RC-P"): K("C-Shift-P"),
    K("RC-LEFT_BRACE"): K("C-Shift-LEFT_BRACE"),
    K("RC-RIGHT_BRACE"): K("C-Shift-RIGHT_BRACE"),
    K("RC-A"): K("C-Shift-A"),
    K("RC-S"): K("C-Shift-S"),
    K("RC-D"): K("C-Shift-D"),
    K("RC-F"): K("C-Shift-F"),
    K("RC-G"): K("C-Shift-G"),
    K("RC-H"): K("C-Shift-H"),
    K("RC-J"): K("C-Shift-J"),
    K("RC-K"): K("C-Shift-K"),
    K("RC-L"): K("C-Shift-L"),
    K("RC-SEMICOLON"): K("C-Shift-SEMICOLON"),
    K("RC-APOSTROPHE"): K("C-Shift-APOSTROPHE"),
    K("RC-GRAVE"): K("C-Shift-GRAVE"),
    K("RC-BACKSLASH"): K("C-Shift-BACKSLASH"),
    K("RC-Z"): K("C-Shift-Z"),
    K("RC-X"): K("C-Shift-X"),
    K("RC-C"): K("C-Shift-C"),
    K("RC-V"): K("C-Shift-V"),
    K("RC-B"): K("C-Shift-B"),
    K("RC-N"): K("C-Shift-N"),
    K("RC-M"): K("C-Shift-M"),
    K("RC-COMMA"): K("C-Shift-COMMA"),
    K("RC-DOT"): K("C-Shift-DOT"),
    K("RC-SLASH"): K("C-Shift-SLASH"),
    K("RC-KPASTERISK"): K("C-Shift-KPASTERISK"),
}, "terminals")

# define_keymap(re.compile("Chromium-browser"),{
#     # K("RC-Tab"): K("C-F13"),
#     # K("RC-Shift-Tab"): K("C-f1"),
# }, "Chromium-browser")

[rbreaves]

And my rabbit hole gets a little deeper. That fix above then breaks Ctrl+Tab for Sublime Text, as it for some reason goes the last previous tab viewed on every release of Ctrl - and despite my best efforts earlier on debugging how xkeysnail works I started to believe that it did in fact keep the modifier held down until the user releases it, but that is clearly not the case.

My first assumption about xkeysnail seems to be confirmed now. The real fix is not the hackish thing I did above, but to rather keep that modifier held down until the user releases it.

[rbreaves]

Fixed the Shift key problem on In App tab switching in the latest forked commit of xkeysnail.

Just found one issue I need to resolve Ctrl+Tab switching tabs in apps works until you press shift. That'll undo the remap, so I am going to make sure I add an exception for that key combination. This does not impact Cmd+Tab (Ctrl+F13 & Ctrl+Shift+F13), but just Super+Tab to Ctrl+Tab rather.

@Jonchun I feel like I am spamming you with updates lol. It appears like I have been able to resolve the issue with xkeysnail and releasing modifiers prematurely. The expected App switching behavior is now happening under xkeysnail plus the In App tabbing occurs properly under Sublime Text.

I am not sure if the maintainer is very active atm so it may take some time before it becomes part of his master, but in the meanwhile my master version of his repo has the patch in it. I will be updating the dev branch shortly with my current xkeysnail config which you can easily play around with when you have the time.

I will need to update the installer though to give users the option of using either kintox11 or xkeysnail. My preference going forward will be xkeysnail and later on adding the ability to check for caret input for the browsers to have the correct keymapping 100% of time, but I have no ETA on that update at this time.

https://github.com/rbreaves/xkeysnail/commit/d79a3bc086a6635ffc3c8f8ef41c646b6f563407

[jonchun]

Awesome -- Lost motivation to do much this weekend after my laptop started crashing and not being nice to me, but will get to this eventually. Don't worry about spam 😂

I started experiencing stability issues (no idea if it's kinto or not) on KDE Neon and I couldn't do anything on it even after a fresh install + run of my script. I'll let you know if I decide to investigate further and it ends up being kinto. https://github.com/Jonchun/macify-linux/issues/37

Since I didn't want a useless laptop, I tried installing Ubuntu 20.04 with the standard Gnome desktop and everything is working great.

I'll probably try your new keysnail stuff on my desktop and switch my laptop to elementaryos and see if i run into any issues there since most of my reports have been on KDE lately.

[rbreaves]

@Jonchun If you do try out the xkeysnail method then just make sure to use my fork of it and my kinto.py script to go along with it.

So far it appears to be extremely stable for me and since no xkb stuff is going on I don't think there's any risk of a system instability/crash from it. Although xkb imo is pretty stable too, once it is figured out lol. Any keymap wonkiness I experienced earlier has been resolved in my fork by holding down the new modifiers when needed. Also been working with other xkeysnail contributors to make sure my changes play nice with the more in depth key remap features of xkeysnail. It really can support some more complicated remaps, things I have already made legit use of for Sublime Text.

https://github.com/rbreaves/kinto/blob/dev/xkeysnail/kinto.py https://github.com/rbreaves/xkeysnail

[rbreaves]

@Jonchun If you want a preview of what's coming up checkout my Alpha branch. I've only tested it under Ubuntu and KDE Neon, but it appears to work well for me.

git pull
git checkout alpha
./xkeysnail_service.sh

That will replace the xkb/kintox11 version of Kinto and you can also add new keymaps in this file here.

~/.config/kinto/kinto.py

Also the new service can be controlled via this

sudo systemctl start xkeysnail
sudo systemctl status xkeysnail
sudo systemctl stop xkeysnail

# monitor
journalctl -l --unit=xkeysnail.service -b

If you want to see more output just stop the service then run the config directly.

sudo systemctl stop xkeysnail
sudo xkeysnail --watch ~/.config/kinto/kinto.py

[jonchun]

Edit: I'm testing this on my KDE neon desktop install.

@rbreaves finally had a chance to give this a shot. I'm working off of your alpha branch since this seems to be your most recent development. Just an immediate thought:

git pull
git checkout alpha
./xkeysnail_service.sh

After running this, the prompt is:

Install Kinto - xkeysnail (udev)
  1) Windows & Mac (HID driver)
  2) Mac Only & VMs on Macbooks
  3) Chromebook

It is not clear to me what these options are asking... Am I supposed to pick what type of keyboard/computer I have? Similar to the original installer? I assumed so and just proceeded with picking "Windows" since i have a windows keyboard.

Might want to get rid of this warning as well:

WARNING: pip is being invoked by an old script wrapper. This will fail in a future version of pip.
Please see https://github.com/pypa/pip/issues/5599 for advice on fixing the underlying issue.
To avoid this problem you can invoke Python with '-m pip' instead of running pip directly.

Finally, looks like the repo is missing the .desktop file? Might also want to include -f on the rm.

cp: cannot stat './xkeysnail-config/xkeysnail.desktop': No such file or directory
rm: cannot remove '/home/jchun/.config/autostart/kinto.desktop': No such file or directory

[jonchun]

Finally, looks like I can't even start the service. Haven't had a chance to google the error yet:

[rbreaves]

@Jonchun Yea, I was getting something like that too initially.. Oh, I know why, the xkeysnail_service.sh script needs to also execute the xhost command. If you just log off and back on that would probably fix it because of a xkeysnail.desktop file that will autorun the xhost command.

I will add that back into the setup script for xkeysnail.

xhost +SI:localuser:root

I ran through a ton of iterations to figure out what worked for KDE and what didn't and I guess by the time I got to the end of it I removed the command from the setup file by accident 😅. The change is in the latest alpha now.

[jonchun]

Where is the .desktop file?

https://github.com/rbreaves/kinto/tree/alpha/xkeysnail-config

I'm not seeing one in here.

[rbreaves]

@Jonchun It's in there now, sorry about that. I just noticed it was missing in my prior commit after my latest round of changes.

I've also updated the systemd to use a shell wrapper that will restart xkeysnail if the config file has changed. This will make it a lot easier to add caret checking support and allow for other types of dynamic keymap updates outside of xkeysnail when needed.

If you have any issues bringing down the latest alpha branch just run this..

git stash # if you want to keep your changes
git reset HEAD~ --hard # clears the last commit
git pull

I pushed an update before I meant to, but you might not have downloaded it any ways. I needed to add a package manager check and bring down inotify. Have not yet tested it under all DE's and OS's, just KDE Neon.

[jonchun]

Just gave the alpha a run on Ubuntu 20.04. (haven't had a chance to test kde neon yet) Worth noting that the setup script assumes pip3 is installed (and doesn't install it if not found, so you might want to add that to the install list).

Additionally, I can't even get it to run.

-- Logs begin at Sat 2020-04-18 07:56:46 EDT, end at Wed 2020-04-22 01:47:10 EDT. --
Apr 21 23:32:26 jchun-Aspire5 systemd[1]: Starting xkeysnail...
Apr 21 23:32:26 jchun-Aspire5 systemd[1]: Started xkeysnail.
Apr 21 23:32:26 jchun-Aspire5 sudo[125063]:     root : TTY=unknown ; PWD=/ ; USER=root ; COMMAND=/bin/bash -c /home/jchun/.config/kinto/xkeystart.sh "/home/jchun/.config/kinto/kinto.py"
Apr 21 23:32:26 jchun-Aspire5 sudo[125063]: pam_unix(sudo:session): session opened for user root by (uid=0)
Apr 21 23:32:26 jchun-Aspire5 sudo[125066]: /home/jchun/.config/kinto/xkeystart.sh: line 3: /usr/local/bin/xkeysnail: No such file or directory
Apr 21 23:35:26 jchun-Aspire5 sudo[147676]: xkeysnail: no process found
Apr 21 23:35:26 jchun-Aspire5 sudo[147678]: /home/jchun/.config/kinto/xkeystart.sh: line 7: /usr/local/bin/xkeysnail: No such file or directory
Apr 21 23:37:26 jchun-Aspire5 systemd[1]: Stopping xkeysnail...
Apr 21 23:37:26 jchun-Aspire5 sudo[147860]:     root : TTY=unknown ; PWD=/ ; USER=root ; COMMAND=/usr/bin/killall xkeysnail
Apr 21 23:37:26 jchun-Aspire5 sudo[147860]: pam_unix(sudo:session): session opened for user root by (uid=0)
Apr 21 23:37:26 jchun-Aspire5 sudo[147866]: xkeysnail: no process found
Apr 21 23:37:26 jchun-Aspire5 sudo[147860]: pam_unix(sudo:session): session closed for user root
Apr 21 23:37:26 jchun-Aspire5 systemd[1]: xkeysnail.service: Control process exited, code=exited, status=1/FAILURE
Apr 21 23:37:26 jchun-Aspire5 sudo[125063]: pam_unix(sudo:session): session closed for user root
Apr 21 23:37:26 jchun-Aspire5 systemd[1]: xkeysnail.service: Failed with result 'exit-code'.
Apr 21 23:37:26 jchun-Aspire5 systemd[1]: Stopped xkeysnail.
-- Reboot --
Apr 21 23:37:42 jchun-Aspire5 systemd[1]: Starting xkeysnail...
Apr 21 23:37:43 jchun-Aspire5 runuser[823]: Failed to get unit file state for keyswap.timer: No such file or directory
Apr 21 23:37:43 jchun-Aspire5 runuser[825]: Failed to get unit file state for keyswap.service: No such file or directory
Apr 21 23:37:43 jchun-Aspire5 sudo[829]:     root : TTY=unknown ; PWD=/ ; USER=root ; COMMAND=/bin/bash -c /home/jchun/.config/kinto/xkeystart.sh "/home/jchun/.config/kinto/kinto.py"
Apr 21 23:37:43 jchun-Aspire5 sudo[829]: pam_unix(sudo:session): session opened for user root by (uid=0)
Apr 21 23:37:43 jchun-Aspire5 systemd[1]: Started xkeysnail.
Apr 21 23:37:44 jchun-Aspire5 sudo[851]: ██╗  ██╗██╗  ██╗███████╗██╗   ██╗
Apr 21 23:37:44 jchun-Aspire5 sudo[851]: ╚██╗██╔╝██║ ██╔╝██╔════╝╚██╗ ██╔╝
Apr 21 23:37:44 jchun-Aspire5 sudo[851]:  ╚███╔╝ █████╔╝ █████╗   ╚████╔╝
Apr 21 23:37:44 jchun-Aspire5 sudo[851]:  ██╔██╗ ██╔═██╗ ██╔══╝    ╚██╔╝
Apr 21 23:37:44 jchun-Aspire5 sudo[851]: ██╔╝ ██╗██║  ██╗███████╗   ██║
Apr 21 23:37:44 jchun-Aspire5 sudo[851]: ╚═╝  ╚═╝╚═╝  ╚═╝╚══════╝   ╚═╝
Apr 21 23:37:44 jchun-Aspire5 sudo[851]:   ███████╗███╗   ██╗ █████╗ ██╗██╗
Apr 21 23:37:44 jchun-Aspire5 sudo[851]:   ██╔════╝████╗  ██║██╔══██╗██║██║
Apr 21 23:37:44 jchun-Aspire5 sudo[851]:   ███████╗██╔██╗ ██║███████║██║██║
Apr 21 23:37:44 jchun-Aspire5 sudo[851]:   ╚════██║██║╚██╗██║██╔══██║██║██║
Apr 21 23:37:44 jchun-Aspire5 sudo[851]:   ███████║██║ ╚████║██║  ██║██║███████╗
Apr 21 23:37:44 jchun-Aspire5 sudo[851]:   ╚══════╝╚═╝  ╚═══╝╚═╝  ╚═╝╚═╝╚══════╝
Apr 21 23:37:44 jchun-Aspire5 sudo[851]:                              v0.2.0
Apr 21 23:37:44 jchun-Aspire5 sudo[851]: Traceback (most recent call last):
Apr 21 23:37:44 jchun-Aspire5 sudo[851]:   File "/usr/local/lib/python3.8/dist-packages/Xlib/support/unix_connect.py", line 119, in get_socket
Apr 21 23:37:44 jchun-Aspire5 sudo[851]:     s = _get_unix_socket(address)
Apr 21 23:37:44 jchun-Aspire5 sudo[851]:   File "/usr/local/lib/python3.8/dist-packages/Xlib/support/unix_connect.py", line 98, in _get_unix_socket
Apr 21 23:37:44 jchun-Aspire5 sudo[851]:     s.connect(address)
Apr 21 23:37:44 jchun-Aspire5 sudo[851]: ConnectionRefusedError: [Errno 111] Connection refused
Apr 21 23:37:44 jchun-Aspire5 sudo[851]: During handling of the above exception, another exception occurred:
Apr 21 23:37:44 jchun-Aspire5 sudo[851]: Traceback (most recent call last):
Apr 21 23:37:44 jchun-Aspire5 sudo[851]:   File "/usr/local/lib/python3.8/dist-packages/Xlib/support/unix_connect.py", line 123, in get_socket
Apr 21 23:37:44 jchun-Aspire5 sudo[851]:     s = _get_tcp_socket(host, dno)
Apr 21 23:37:44 jchun-Aspire5 sudo[851]:   File "/usr/local/lib/python3.8/dist-packages/Xlib/support/unix_connect.py", line 93, in _get_tcp_socket
Apr 21 23:37:44 jchun-Aspire5 sudo[851]:     s.connect((host, 6000 + dno))
Apr 21 23:37:44 jchun-Aspire5 sudo[851]: ConnectionRefusedError: [Errno 111] Connection refused
Apr 21 23:37:44 jchun-Aspire5 sudo[851]: During handling of the above exception, another exception occurred:
Apr 21 23:37:44 jchun-Aspire5 sudo[851]: Traceback (most recent call last):
Apr 21 23:37:44 jchun-Aspire5 sudo[851]:   File "/usr/local/bin/xkeysnail", line 6, in <module>
Apr 21 23:37:44 jchun-Aspire5 sudo[851]:     cli_main()
Apr 21 23:37:44 jchun-Aspire5 sudo[851]:   File "/usr/local/lib/python3.8/dist-packages/xkeysnail/__init__.py", line 61, in cli_main

It seems like it is complaining about keyswap? I thought this new xkeysnail replaced that service? I tried installing kinto with setup.py again, and then runnign the xkeysnail installer but it doesn't seem to work.

[jonchun]

Just gave it a run on my KDE Neon desktop. (latest alpha). In the first 5 minutes I've used it, it's working GREAT. the task switcher works perfectly too.

Interestingly enough, in sublime, ctrl+tab seems to be tabbing reverse while ctrl+shift+tab switches forward. It also seems to go out of order sometimes (instead of going to the adjacent tab it'll jump a tab)

In firefox, ctrl+tab / ctrl+shift+tab seems to work fine and in the correct direction.

i don't really use this hotkey so doesn't affect me too much, but figured I'd report it anyways)

[rbreaves]

Yea, my sublime Ctrl+tab jumps around a bit too, but that is the actual default behavior.. its sort goes by some sort of most recently used thing. And thanks for reporting back an update, I've been figuring that it'd work much better overall, particularly in KDE given the xkb shortfalls.

I just sent another update in the alpha branch, nothing major though. Prepping the browser based wordwise solution, and getting nearer for that release but it isn't 100% ready just yet, still a couple of minor things to work out with the new script, but it will be able to update the xkeysnail config and have it change the browser behavior appropriately from all of my testing thus far.

Also need to add the pip3 install as you mentioned.

Once that is completed it should be possible for me to add the xkeysnail option to the main setup file and then merge that into dev, and lastly master. Xkeysnail will become the recommended method and the readme will undergo some major changes too. Most of it will be archived into a separate readme file though and a much simpler readme will be left in its place covering just xkeysnail based modifications.

[jonchun]

Ok. Re-report on Ubuntu 20.04. I pulled the latest alpha again and ran the installer. This time it seems to be working perfectly.

I am really liking what you did with the xkeysnail switch, and at least from light usage, it seems that even on KDE, things seem to be faster/more responsive in general and less buggy. Will need to see if it continues.

[rbreaves]

Not sure which commit to tie this too, but do want to make note of a known xkbcomp bug in regards to types that can cause a segfault. Although moving away from it may make it irrelevant and I did resolve it for KDE afaik.

https://gitlab.freedesktop.org/xorg/app/xkbcomp/-/issues/8

[rbreaves]

@Jonchun The dev branch now has an updated ./setup.py installer and I believe I have worked out most issues with the xkeysnail implementation.

Documentation changes have also been made. Not sure when I will merge it to master due to caret/input related stuff.

The caret/input checking for Firefox and Chrome to have proper Back/Forward hotkeys is a little buggy, but it generally works. I will probably need to update xkeysnail source to detect the keymap change natively at some point though, instead of restarting the service. I also don't think layering another keymapper on top like I could do with xkb will be an option with xkeysnail, but not entirely sure either, will have to test later.

[jonchun]

I'lll give the dev branch a shot. To clarify, are you saying that the dev branch now has the xkeysnail implementation in setup.py, or do I still need to run the separate xkeysnail script? What are the recommended steps for uninstalling/upgrading the previous alpha branch to the current dev branch?

Haven't been using it heavily, but from light use, the xkeysnail implementation in the alpha branch has been working great and similarly to what I noted before, it seems less buggy/laggy than the original that I played with.

[rbreaves]

Correct, you can now run ./setup.py & it will apply proper shortcut keys & then execute the same standalone script that you ran before.

Installing on top of itself or the xkb keyswap is absolutely fine too. Only thing I don’t really recommend is the experimental Firefox & chrome back/forward hotkeys.. it’s just buggy atm & I might have to comment that out before merging to master..

I want to keep it but I really need to find a better way to implement it.

[jonchun]

Tested the dev branch on my laptop (Ubuntu 20.04) and its working great so far. I didn't bother trying the ff/chrome hotkeys since you said it's buggy and I don't even know what those shortcuts are since I never use hotkeys for back/forward.

[rbreaves]

Thanks for the feedback @Jonchun , I am probably going to let Dev sit where it is at for a couple of days and then add a switch to the script to detect if a person is on the master branch or not, if they are on master then I will disable experimental features that are accessible on the Dev branch (granted there will only be that one).

I think the development of new features may stall compared to the pace I had been going at. For the most part I want the focus to be on adding in the few shortcuts that may differ in cross platform apps. I also need to revisit my patch on xkeysnail and I will be closing this thread as it would appear xkeysnail has resolved the weirdness that is Alt-Tab lol.