Mapping Cmd-Tab to Alt-Tab instead of Win-Tab

[RedBearAK]

I installed Kinto on a Raspberry Pi 4B running Twister OS. I believe it's just another Debian-based variant with XFCE as the DE. Many shortcuts work well, including copying from one application with Alt-C and pasting with Alt-V. Even works in the terminal app. New tabs, closing tabs, quitting applications, many things work just like on my Mac. It's great.

What I can't understand is that Kinto remapped the standard Alt-Tab task switching function to Win-Tab. It was already on Alt-Tab to begin with, why would Kinto change it to using the Windows key? This makes little sense and is not the way keys are remapped when installing Kinto on a MacBook. On a MacBook everything maps correctly to the Command key, including task switching.

This is on a wireless USB keyboard with the keys in this order to the left of the space bar:

Ctrl - Fn - Win - Alt - Space.

Why would Kinto do this on a "Windows" keyboard vs what it does on a "Mac" keyboard, and how can I fix it? I've tried to get used to it but I keep accidentally killing terminal processes when I inevitably forget and try to switch away with Alt-Tab.

[Editing with solutions discovered in the thread below: ]

If the Desktop Environment is XFCE but the Kinto install script doesn't recognize the distro or the DE properly, it fails to apply system level shortcuts. This leads to Alt-Tab "Cycle windows" function shifting to Win-Tab because the system now sees the Win key as the Alt_L key.

To fix (only if your desktop is XFCE):

1. Open the file ~/.config/kinto/kinto.py with any text editor and comment out the lines that say "# Default not-xfce4" at the end, and uncomment the lines below them that just say "# xfce4" at the end. Save the file.

2. Run the command "sudo systemctl restart xkeysnail" to restart Kinto.

3. Then use the Window Manager app which may be found either in a Settings menu or in the XFCE Settings app, to modify the shortcut for "Cycle windows" and the shortcut for "Cycle windows (Reverse)". Press Alt-Tab for "Cycle windows" and it will show "Ctrl+Backslash" instead of "Alt+Tab". Press Shift-Alt-Tab for "Cycle windows (Reverse)" and it will show "Ctrl+Shift+|" instead of "Alt+Shift+Tab". Alt-Tabbing between windows should now work.

This breaks Kinto in IceWM. :-(

To fix in IceWM, do this in a terminal:

xhost +SI:localuser:root

Here is how to fix the Al-Tab Cycle windows mapping in IceWM:

Look for a text file called "preferences" in the hidden ".icewm" folder in your home folder. The path will be /home/YOURUSERNAME/.icewm/preferences . There is no extension on the preferences text file.

If it doesn't exist, you can create an empty text file with that name. In the preferences file, make sure it has a line like this:

KeySysSwitchNext="Ctrl+backslash"

This will only work if the XFCE system level shortcuts were applied by Kinto setup. Remember not to capitalize the "backslash".

If you also want to do reverse window cycling, add this line:

KeySysSwitchLast="Ctrl+Shift+backslash"

I don't know what KeySysSwitchClass will actually do, but you can set that too, it defaults to "Alt+grave".

KeySysSwitchClass="Ctrl+grave"

To activate, restart IceWM from the Logout submenu. You don't need to logout if you have the "Restart IceWM" option showing. This takes less than a second to reload the window manager with the new settings.

[rbreaves]

That doesn't sound like intentional behavior tbh, but I can explain what the Alt-Tab remap should be doing.

1st these keys are being transformed and I will list them in the order of left to right (on the left side).

GUI	Ctrl	Win/Alt	Alt/Cmd	Spacebar
Win/Super	Alt	RCtrl	Spacebar

Terminal	Ctrl	Win/Alt	Alt/Cmd	Spacebar
LCtrl	Alt	RCtrl	Spacebar

So regardless this is what we're working with as a base for ALL other keymaps, not the physical keys you think you are looking at. What this means is that Alt-Tab shifted over a key (on Windows keyboards at least) and yet.. on macs the Window/App switching occurs on Cmd-Tab, not Alt-Tab.

To fix it so that the App switching happens correctly it means that remapped Ctrl-Tab needs to act as Alt or Cmd-Tab (the key immediately left of the spacebar). That poses an issue though because the REAL Ctrl key still needs to operate normally to tab switch in browsers and code editors and it does.. Super-Tab (the furthest physical Ctrl key to the left) does in fact activate Ctrl-Tab when it should thus tab switching internally within a program.

That is the higher level view/explanation for what might look strange when you look at the key remap file initially. Basically the Alt-Tab binding has to go away, as to not accidentally activate it on the actual Alt key, but on the physical Cmd key location simply remapping it to Ctrl-Tab won't do because it interferes with the internal Tab switching of various apps.

What I end up doing is remapping Cmd-Tab (first modifier left of spacebar) to something like Ctrl-F13 because I know I can safely using F keys above 12 without interfering any actual key combos and xkeysnail is smart enough to only remap that key combo on the RCtrl key which I use as the Cmd key, LCtrl and Super will act as the further Left or physical Control in most cases.

I admit... it was a very pains taking process to correctly remap those keys, especially under KDE, which is what led me to using xkeysnail in the first place over my custom kintox11 app and xkb solution.

Also just to mention Fn keys are hardware keys, so there will never be any possibility of remapping that particular key unless your keyboard or laptop bios supports changing it.

[RedBearAK]

So... I guess that brings up a question I've been meaning to ask for a while. Is Kinto not capable of just leaving the keyboard mapping alone and just changing the keyboard shortcuts? I noticed in eOS that if I tried to use the keyboard shortcut settings in the built-in settings app to fix using Cmd-Space to open the Application Menu (which Kinto used to break before 1.1-4, I think) the keys were remapped so eOS would call the Ctrl key "Cmd", and so on. But before activating Kinto, eOS knew exactly what each Mac keyboard key was. This made everything very confusing. I don't really understand the point of remapping the keys on an actual Mac keyboard to make it... type like a Mac? It's already a Mac. Can't Kinto just change the keyboard shortcuts and leave the keyboard itself alone in that case?

You seem to be saying as part of your explanation that you're going to extra trouble to, if I understand, avoid clobbering some pre-existing keyboard shortcuts. Which is commendable and great for the people who need those shortcuts, but I really just wanted to pretty much wipe all the pre-existing Linux/Windows style Ctrl-based shortcuts in favor of all the Mac-style Cmd-based shortcuts that I use constantly. Most especially common shortcuts like Cmd-Tab/Alt-Tab.

Am I confused about what Kinto is capable of doing? It works so well for the most part, especially on a Mac, but are you saying that there is no easy way to get App switching back onto the Alt-Tab keys, at least one a non-Mac keyboard? What if I connect an actual Mac-style physical keyboard to the Raspberry Pi? I have tried choosing the Mac option when setting up Kinto but that never seems to work out well.

[rbreaves]

I had a really long response typed up before realizing what your actual issue probably is. There are 2 mac keyboard setup options, but if you install the 2nd on top of the 1st then maybe those keymaps can get really screwy as a result (although I wouldn't know why you'd deviate from 1, if 1 actually applied the right settings for the mac keyboard).

I digress though, try this, assuming you're on the 2nd install option. You shouldn't need to re-install kinto on the 2nd option after applying this command, but if you are on the 1st mac keyboard option then yea.. run through the installer again and put yourself on the 2nd keyboard option instead.

echo '0' | sudo tee -a /sys/module/hid_apple/parameters/swap_opt_cmd;echo 'options hid_apple swap_opt_cmd=0' | sudo tee -a /etc/modprobe.d/hid_apple.conf;sudo update-initramfs -u -k all

The reason for doing it this way is simply to consolidate differences btwn Apple and Windows keyboards before applying the actual Kinto remaps. Less work to maintain it, sorta, but I still do because there's no way of getting around the limitations of working with Apple keyboards on macOS and running Linux inside of a VM.

I mean technically I do know how to remap the keys while running macOS, but that would then screw with macOS, unless I watch for VM software being active, and require that users install Kinto there too lol. I am not going to do that just to eliminate a setup option. Besides that I am writing a new installer that won't ask users to pick their keyboard type any more, it will ask you press your keys and it will remap it correctly regardless, including chromebooks and more importantly configurations I have never seen.

[rbreaves]

Crap lol, I don't know if ran that command already but I just updated it to say 0, it was setting a 1 earlier and that is not what you want if you have the driver available. Although I suspect the command won't actually do anything at all - because the HID driver just isn't there on your distro or the raspberry pi distro.

[RedBearAK]

Ohhhh... I was going to say I always see the installer script setting that to 1, so what is this supposed to do? But you think the driver isn't there? I'll try it again with 0.

How would I check for the HID driver?

[rbreaves]

How would I check for the HID driver?

I am not sure.. probably some sort of lsmod or probe like command, but it's not really important, if the command doesn't run successfully it won't hurt anything from having ran it. It will likely give an error, but again it's fine.

[RedBearAK]

Side note: Because of all my installing and uninstalling Kinto there are like 30 lines of "options hid_apple blah blah blah" in my /etc/modprobe.d/hid_apple.conf file. I used nano to clear all the extra lines out.

[RedBearAK]

Neither the zero nor the one had any effect on my Alt-Tab switching function now being on Win-Tab on the MX laptop. Uninstalling Kinto puts it back to Alt-Tab, but of course then I lose all the sweet Mac shortcuts.

Is there no solution for this on PC keyboards? It's pretty annoying. My motor cortex really wants to keep Alt-Tabbing all the time but now all that does is bring up the preferences dialog in my web browser on the MX machine. (Falkon, based on Firefox. Edit: Um, I mean Chrome.)

[rbreaves]

To be honest I am surprised that you're having any issue with it on mac or windows based keyboards.. I mean the layouts are pretty standardized, the location of an Fn key has no bearing on the remap.

I cover the 4 most common keyboard layouts out there that I'm aware of, Standard Windows, Official Apple, non-official Apple (or official apple with no HID driver) and chromebooks. I think even HHKB tend to qualify as a chromebook layout as well - although it has dipswitch's on it and be default probably doesn't replace capslock with Super.

And physically speaking your Alt-Tabbing ought to be in the normal location that it is always in under Linux, Windows or macOS - so if it is shifting on you then there's definitely something wrong - what I am not sure, because the only thing I could figure was that you were running a Win/Mac remap on an Apple keyboard or 3rd party Apple keyboard without HID driver support (of course Windows doesn't need nor use an Apple HID driver lol).

Trying to think what else I can have you do and I guess if you temporarily removed or commented out this code block and then restart kinto you could capture your modifier keys for me and let me verify what your current keymap actually looks like..

~/.config/kinto/kinto.py

...
define_conditional_modmap(re.compile(termStr, re.IGNORECASE), {
...
}
...

restart kinto

sudo systemctl restart xkeysnail

The lastly install and run xbindkeys, that can tell me what is going on with each key.

sudo apt install xbindkeys
# run this, it will fail and tell you to create some sort of .rc file, just copy and paste that command and run this command again
# Do this for all 3 modifier keys on the left side, ctrl, super/alt, alt/cmd
xbindkeys -k

# Can also test out GUI based keybinds too, helpful to see things like Cmd-Tab in action
xbindkeys -mk

That's literally the last bit of debugging advice I know to give to help figure out what is going on with your configuration. Obviously I will still be here to help though 😅.

[RedBearAK]

To be clear, I have not had this problem in any of the Macs (MacBook Pro 2011, MacBook 2007, iMac 2007) that I have tried Kinto on (mostly with eOS). This is only cropping up so far on PC keyboards. One is the cheap wireless keyboard plugged into my Raspberry Pi 4B, which oddly enough is physically styled like an Apple wireless aluminum keyboard but has a Windows key and no Command key. The other is this ancient 32-bit laptop, which also has a Windows key and originally came with WinXP back in 2002.

But on Macs I haven't seen this happening.

I would absolutely love to help you get to the bottom of why this is happening and how to fix it.

[RedBearAK]

Stupid question perhaps, but where exactly is this code block you want me to comment out? What file?

And no uninstalling Kinto, just restart xkeysnail?

[rbreaves]

I apologize I thought I had mentioned the file location. I was kinda multitasking at the time 😅.

~/.config/kinto/kinto.py

And yea restarting kinto via sudo systemctl restart xkeysnail should be fine.

I also updated the original post above with the file location that contains the code block. I do wish there was a better way to disable that tbh so that anyone could debug without having to edit a file and then restart the service, but it is what it is. It is important that the Terminals map their keys differently from the rest of the GUI based apps.

[RedBearAK]

Here is the result from xbindkeys:

Ctrl key: m:0x40 + c:133 Mod4 + Super_L

Win key: m:0x8 + c:64 Alt + Alt_L

Alt key: m:0x4 + c:105 Control + Control_R

Here is what Alt+Tab is doing: m:0x4 + c:191 Control + XF86Tools m:0x4 + c:105 Control + Control_R

The xbindkeys -mk window seems to be unable to capture the keycodes for Win-Tab. App switching happens instead.

For good measure here's the Tab key: m:0x0 + c:23 Tab

The key mapping by Kinto seems to be fluctuating back and forth between the Kinto keymap and the normal keymap, as I'm switching between the browser and the terminal. In the browser I can only switch back to the terminal with Win-Tab, but when in the terminal I have to press Alt-Tab to switch back to the browser.

Had to get out of IceWM and use XFCE because IceWM kept capturing the Win key to activate the start menu.

[rbreaves]

All of those keys look normal and it isn't that surprising that your DE might have bound to the Alt-Tab combo in a way to prevent xbindkeys from capturing it. XF86Tools is also normal as that is what F13 often results in any ways. I mean if your physical Left Alt key is the key right next to the space bar and is being remapped to RCtrl then xkeysnail is doing what it is supposed to.

The Win key being Alt is proper, and Ctrl resolving to Super looks normal. I don't see anything abnormal there. Also Tab should always resolve to Tab, except when the Left Alt (RCtrl) key is held down, that's when it goes to XF86Tool ( aka F13).

[rbreaves]

I should note that unless I explicitly test Kinto against a DE then the Alt-Tab stuff may not work as expected since it is somewhat dependent on how the DE is coded. KDE specifically had issues until I moved from xkb and on over to xkeysnail implementation of Kinto and Budgie was hardcoded in a way to prevent Alt-Tab from working via any Ctrl key combo until I patched Budgie to accept any keybinding.

I'd like to say though.. if a DE is coded in a sane way then there's no reason for my Alt-Tab remap to not work lol.

Also now that I think about it.. if you are using XFCE then it should be using Ctrl + backslash for app switching, not Ctrl + F13 (xf86tool) and that could be part of your issue atm. I do tests on chromebooks however running xfce.. and it applies correctly there - it should apply on xfce in general though, but I guess later I will spin up Enso OS (xfce) and make sure the Alt-Tab is working properly there. I have no idea about IceWM btw.

[RedBearAK]

Just updated my ancient laptop running MX 19.2 (32-bit) to the new 1.1-6 Kinto release. Ran the uninstall script before reinstalling from a newly cloned Kinto folder. Chose 1 and 1 as the options, as always.

The problem of Alt-Tab task switching shifting onto Win-Tab remains. Everything else I try still works well.

New tab (Alt-T), close tab/window (Alt-W), new window (Alt-N), quit application (Alt-Q) (for windows that don't respond to "close window" shortcut), select all (Alt-A), cut, copy, paste (Alt-X/C/V), undo (Alt-Z), go to address bar (Alt-L), print (Alt-P).

All the common things I use constantly on my Mac work with the Mac-style shortcuts, based on the physical Alt key. Except task switching. That's still stuck on Win-Tab whenever Kinto is active.

Still seeking a way to troubleshoot and solve this. Will also try updating the Raspberry Pi 4B that started this thread. Not expecting any change.

[rbreaves]

Could you also just.. I don't know open a control panel like settings menu in your specific DE and just manually rebind your Cmd-Tab keys to handle the app switching? (it needs to be bound to Ctrl-XF86Tools (F13) if it is successful, unless the DE is like XFCE then perhaps Ctrl-backslash and changes to the ~/.config/kinto/kinto.py file as well to reflect that.)

Since you are using a distro and DE that I have not touched - it also means that the manual remap I do on the system level can't possibly be taking place either, so it is somewhat dependent on you to remap it on the system level after the install completes. Sorry if I failed to mention that earlier, I was rather confused about what part of Kinto you have really been having issues with, but it seems like it is more of a DE issue in that I don't have logic for it.

You can also certainly take a look at the ./setup.py file and see where all the distro/de specific logic resides that sets gnome, mate, xfce, and kde to use slightly tweaked system level shortcuts. Just search for gsettings and you will immediately go there.

Unlike Windows I do make slight shortcut binding changes on the system level too given that no one can agree on what shortcuts to use and it simplifies the main kinto.py config file greatly - to just make a few changes in accordance with my #44 shortcut translation tables.

[RedBearAK]

Yeah, so when I run the install script on these machines, I always hit enter to say "Yes" to the system level shortcuts (even though as a normal end user I really have no idea what the system level shortcuts even do), but the script always says something like this:

distro: raspbian de: xfce A supported OS and DE was not found, you may not have full system level shortcuts installed.

Could that really be the heart of the matter right there? That the script is just not recognizing the distro or DE and therefore refuses to apply the system level shortcuts?

Again, these are (as far as I know) both still just Debian-based distros. So you think I can just hack setup.py to recognize my distros and it will work? I am entirely unfamiliar with python, but I can give it a try.

[RedBearAK]

I am not immediately seeing a way to edit the system keyboard shortcuts, at least in the Raspbian-based Twister OS user interface. I'll keep looking.

[rbreaves]

Yep, sounds like that is the heart of the issue, I guess in the future I should highlight that message in red if it isn't lol. I mean it'd be nice to not modify system level shortcuts at all - I just don't care for the maintenance cost involved vs just doing slight tweaks to make all the linux distro share more similar shortcut keys. I tend to pick the most commonly used ones and the distros that try to be special will get theirs wiped.

During an uninstall though I attempt to restore them or do a full factory reset, whichever the user wants to do.

[rbreaves]

Also it is difficult initially to find the proper terminal commands to set the DE binds correctly. I would initially just look at modifying it via the normal GUI interface and then dig deeper if you want/care to. I often have to use dconf with gnome to find what I am looking for, but KDE and XFCE are different.

I think my notes for grabbing and dumping keybinds is all contained in an excel doc on thread #44.

[RedBearAK]

OK, so I found the proper keyboard settings, inexplicably hidden in a dialog called "Window Manager" in the XFCE settings app. There I am able to see what XFCE thinks the shortcut is for "Cycle windows", which appears to be the Alt-Tab task switching we're talking about. Initially, it is set as Alt-Tab. Duh. Which of course is why it is activated with Win-Tab now.

So, no problem, just change it, right? Well, I can certainly change the keyboard shortcut. When I use Alt-Tab, it shows "Ctrl-Tools".

I'm guessing that's the XF86Tools you're talking about?

Only problem is, it doesn't work. Alt-Tab continues to invoke the preferences dialog here in Falkon (Chromium-based browser). With the XFCE Window Manager window in front, nothing happens when I Alt-Tab.

Even stranger, I can change "Cycle windows" back to Win-Tab (it shows Alt-Tab again), but when I try to change the "Cycle windows (Reverse)" setting back to saying Shift-Alt-Tab by pressing Shift-Win-Tab, weird things happen. I'll try to describe it clearly.

Shift-Win-Tab is recognized as just Alt-Tab, and conflicts with the normal "Cycle windows". The shift key seems to be ignored entirely.

Win alone is recognized as "Alt L". Understandable, due to Kinto.

Win-Shift is recognized as "Next Group". Whatever that means. Add Tab to Win-Shift and it again becomes seen as just "Alt + Tab".

So in short, the keyboard shortcut for "Cycle windows" can be changed manually, at least in XFCE. But it doesn't work when it is changed to physical Alt-Tab, logical "Ctrl-Tools". That shortcut just keeps doing whatever it's doing under Kinto.

This seems very similar to the problem I was having in eOS (on a MacBook) a while back when Kinto was still breaking Cmd-Space opening the Application Menu. I tried to just manually fix it with the eOS keyboard shortcuts settings, but when I would change it back to Cmd-Tab (which eOS would recognize as Ctrl-Tab), that keyboard shortcut just wouldn't do anything. Luckily, Kinto stopped breaking that particular shortcut, as far as I know. Around when 1.1-4 came out.

[rbreaves]

Oh, if XFCE is your window manager then you definitely want the ./setup.py to apply the xfce based commands against your distro and apply the xfce based shortcuts in ~/.config/kinto/kinto.py by uncomment those lines out (unless it is just for a chromebook then leaves those alone).

XFCE cannot accept Ctrl+Tools to toggle your windows, you need the Ctrl+backslash I mentioned earlier to be active in your kinto.py file and then you can manually set the Window Manager app switcher keybind with that combo instead just fine.

I do not know why XFCE does not accept F13/Tools but regardless it is what it is.

[RedBearAK]

Oh, if XFCE is your window manager then you definitely want the ./setup.py to apply the xfce based commands against your distro and apply the xfce based shortcuts in ~/.config/kinto/kinto.py by uncomment those lines out (unless it is just for a chromebook then leaves those alone).

XFCE cannot accept Ctrl+Tools to toggle your windows, you need the Ctrl+backslash I mentioned earlier to be active in your kinto.py file and then you can manually set the Window Manager app switcher keybind with that combo instead just fine.

I do not know why XFCE does not accept F13/Tools but regardless it is what it is.

OK, this sounds promising. If I am parsing this message correctly this means I can just uncomment some lines in kinto.py related to XFCE and then (wild guessing here) just restart the xkysnail service? And then it might start working?

[rbreaves]

Yea, after you update the kinto.py to comment out the Tools/F13 remap and uncomment the backslash you'd just restart the service and then manually click whatever you need to in the Window Manager settings to reset the app switching keybind.

Sorry it took so long to figure that out, it wasn't immediately obvious to me that you were dealing with XFCE or that the installer wouldn't have attempted to apply those keymaps as it does support XFCE in other circumstances than just galliumOS for chromebooks (although that was the 1st one supported, as well as a motivator for the project).

[RedBearAK]

Well, I tried commenting out the "Default not xfce4" lines and uncommenting the "xfce4" lines in kinto.py. Stopped and started xkeysnail.service.

No good at first. But now I'm able to change the keyboard shortcut and it says Ctrl+Backslash!

And it works!

Holy schmoly.

So basically we need to make Kinto better at applying system level shortcuts when the DE is recognized, even when the distro isn't.

This is on the MX laptop, BTW.

[rbreaves]

Yep, that would be the issue 😅. Glad we've solved it, but yea will keep this open until a new commit has been made either by you or myself to check for just xfce and apply the right system level shortcuts.

Obviously there was something wrong really happening given the title of the issue ticket lol, but yea it is also probably one of the most difficult things to solve without clobbering something else.

Afaik I might be the only one that has solved it for both Linux and Windows more or less lol, but @jonchun sticking with me for what seemed like an ungodly amount of time and attempts while I worked out issues under KDE really helped too. It made the solution work a lot better across the board in the end.

[RedBearAK]

Just logged out of XFCE and back into IceWM (XFCE uses twice as much RAM) and for the moment the Alt-Tabbing is still working. Going to try rebooting and see if it still works. No idea how I would edit the keyboard shortcuts in IceWM like I did in XFCE. I'm sure there's some way.

If this still works after a reboot I'll try the same procedure on the Raspberry Pi / Twister OS (Raspbian). Since it's also XFCE I see no reason why it won't work there too.

[RedBearAK]

OK, stop celebrating. Just realized that while Alt-Tab works now none of the other shortcuts are working. It's as if Kinto isn't even working.

[rbreaves]

Well I may have to spin up a MX Linux distro and that Twister OS under qemu or something to really test things out, but I wouldn't understand why Ctrl-backslash would work and not other shortcuts (xfce has some differences, but not that many I don't think). It's also pretty rare for me to bind to keys above F12 which is the only real hangup XFCE has. I also know that I tested Kinto against Enso OS awhile back which is xfce based so I am curious at why it'd fail on other xfce distros.

Although I have no real idea of the impact IceWM or other unsupported DE's or Window managers could have. Ideally the user would just go to their keybinding app and manually apply everything they need/want unless they want to take the time to help me support it in my installer.

[RedBearAK]

It appears to be IceWM that is the problem now. Which is disheartening, because it uses so much less RAM on thos old machine that really struggles with its max of 1GB RAM.

Going back to XFCE, everything seems to work. Not just Alt-Tab but all the other stuff too. So Kinto is definitely working. The Alt-Tab fix is still functioning after a reboot, although I will have to remember to fix that manually after modifying kinto.py.

But everything except Alt-Tab was previously working in IceWM, and now it all seems to be broken. The xkeysnail service crashes when I try to restart it. While running IceWM.

Back in XFCE, everything is fine.

So it should still work on the RPi4.

And if we can adjust setup.py to be better at recognizing XFCE on strange distros, the manual Alt-Tab shortcut fix after install shouldn't be necessary, correct?

[rbreaves]

Switching back and forth btwn XFCE and IceWM could leave you on a port besides 0 or 0.0 for the display.. echo $DISPLAY to find out.

The xkeysnail.service file, which the path will appear if you run sudo systemctl status xkeysnail may be hardcoded to use a particular display port.. 0 or 0.0 most likely. That could be causing xkeysnail to fail and is the most likely cause of an intermittent failure of that kind.

You can inspect and edit the xkeysnail.service file with vi, vim, nano or whatever you want once you have that path.

[RedBearAK]

Had another mini heart attack when I jumped on the RPi4 when I found that the xfce4 lines were already uncommented! But then I remembered to open Window Manager and manually fix "Cycle windows" and "Cycle windows (Reverse)". Now they say Ctrl+Backslash and Shift+Ctrl+| (pipe symbol). Sound right?

[Edit: My brain is so fried I just now realized those are of course on the same key, at least on a US keyboard. facepalm]

And they work. As do all the other shortcuts, as far as I can tell.

So now to work on IceWM per your most recent post.

[RedBearAK]

You should grab yourself a Raspberry Pi 4B with 4GB or 8GB and try this Twister OS. With Kinto working now I could easily forget that I'm not using a real Mac. The UI is a really well done copy of macOS and Kinto is the icing on the cake.

[rbreaves]

I do have a couple of raspberry pi's and I have never heard of Twister, but I'd certainly take a look at it. On the x86 side though there's Ubuntu Budgie that gets to be very mac like out of the box. Enso OS is close too w/ global menus and parts of elementaryOS.

I also have a private project going on that is sorta reshaping a very well known and popular distro.. that tends to look very ugly by default, but I have found it having more promise than just about anything else out there in way of stability and configuration. When I have time to really work on it and complete it I will be making that repo public.

[RedBearAK]

Switching back and forth btwn XFCE and IceWM could leave you on a port besides 0 or 0.0 for the display.. echo $DISPLAY to find out.

The xkeysnail.service file, which the path will appear if you run sudo systemctl status xkeysnail may be hardcoded to use a particular display port.. 0 or 0.0 most likely. That could be causing xkeysnail to fail and is the most likely cause of an intermittent failure of that kind.

You can inspect and edit the xkeysnail.service file with vi, vim, nano or whatever you want once you have that path.

XFCE display is ":0.0" and IceWM display is ":0". But Kinto has always been working in IceWM before now. I don't recall ever trying to restart xkeysnail.service while in IceWM however.

I tried to change the kinto.py file back to the original to at least have the rest of the shortcuts working in IceWM, but xkeysnail still crashes when I try to start it up. I've booted this machine many times straight into IceWM and Kinto was working, so I don't really undersand what's happening now.

It's cool that we finally got it working in XFCE, but I want Kinto work reliably everywhere.

[rbreaves]

Well this is the file you're dealing with and indeed it will be hardcoded and the difference between 0 vs 0.0 I do believe is enough to crash Kinto. You can actually try commenting out the Display line altogether, some DE's do not need it set while others do and I made a call a long time ago that it is better to hard set it all the time and be wrong than to try and guess when it is and isn't needed.

Sucks I know.. but I was getting too many issue tickets when I was trying to guess at it because some users on the same distro and de as me would have issues and others wouldn't so I just said fine - I will set it all the time. But again maybe you can comment it out completely and be fine.

https://raw.githubusercontent.com/rbreaves/kinto/master/xkeysnail-config/xkeysnail.service

...
# Environment=DISPLAY={displayid}
...

[Unit]
Description=xkeysnail

[Service]
Type=simple
KillMode=process
ExecStartPre=/bin/bash -c "{xhost} +SI:localuser:root && /sbin/runuser -l {username} -c {homedir}/.config/kinto/prexk.sh"
ExecStart=/usr/bin/sudo /bin/bash -c '{experimental-caret}{homedir}/.config/kinto/xkeystart.sh /tmp/kinto/xkeysnail/kinto.py'
ExecStop=/bin/bash -c 'me=$$;ps -ef | grep \'[t]mp/kinto\' | awk -v me=$me \'$2 != me {print $2}\' | xargs kill;/usr/bin/killall dbus-monitor;/usr/bin/killall xkeysnail;{kill-caret}'
Restart=on-failure
RestartSec=3
Environment=DISPLAY={displayid}

[Install]
WantedBy=graphical.target

again to discover its path just run that status command.

sudo systemctl status xkeysnail

After you edit the file and try starting the service up again it will complain about needing you to run a sudo systemctl reload command I think.. or something like it. That's fine you'll want to run what it tells you to run and then try starting it again.

[RedBearAK]

I do have a couple of raspberry pi's and I have never heard of Twister, but I'd certainly take a look at it. On the x86 side though there's Ubuntu Budgie that gets to be very mac like out of the box. Enso OS is close too w/ global menus and parts of elementaryOS.

I also have a private project going on that is sorta reshaping a very well known and popular distro.. that tends to look very ugly by default, but I have found it having more promise than just about anything else out there in way of stability and configuration. When I have time to really work on it and complete it I will be making that repo public.

Sounds very interesting. I look forward to seeing it. Manjaro? LOL. That's pretty damn ugly.

I've tried Budgie a bit on Solus. Seems quite nice. I'm going to have to look up that Enso OS. You got my attention with global menus.

You'll find Twister at raspbian-x.com. It's actually a combined simulation of macOS and Windows 10 where you can switch between the two UIs. I hope they will come out with a new version of Twister when the 64-bit version of Raspberry Pi OS gets out of beta.

[rbreaves]

Sounds very interesting. I look forward to seeing it. Manjaro? LOL. That's pretty damn ugly.

God no lol, last thing I want to be dealing with is Arch, no offense to the guys that use it and like it and participate in AUR. I hear good things, but meh I don't think the lack of speed of patching is as big of barrier as other things tend to be.

What I am working on is a derivative of Ubuntu is all I will say atm lol. The script will be minified down to only asking for a few specific things and it will then apply all the patches you may need - and I have no fear of major or breaking changes coming down the line by basing my work on their stuff. It could still happen, but I know they won't be going out of their way to make my life or anyone's life more difficult. The UX is the focus, not the developers opinions, in fact the primary developer of it doesn't even use it all of the time himself, I think he's an Arch linux guy lol.

And yea that TwisterOS looks very interesting, I'd be even more curious to try it in VM if they had an x86 version. I really don't mind adding support for any distro that makes use of a global menu out of the gate. If it has that 1 feature then I tend to want to support.

If the developers of a distro purposely kill it or speak out against global menus such as elementaryOS, Ubuntu (Gnome3 team), and possibly others but those are the 2 big ones then I am less inclined to support them vocally as they've become far too opinionated about UX for my taste. It's very sad in elementaryOS's case, as I've said to others before I feel like they got a lot right, but at the end of the day it doesn't matter if they're going to practically go out of their way to make the UX suffer because of their opinions.

Some apps are like Firefox though, in that the pursuit of creating a custom UI they've made it really difficult to support Global Menus in general and thus it has now been lost - but that is because the Firefox team only cares about Gnome3 atm and that may always be the case. They have no loveloss in moving away from it - one less patch for them to maintain in their eyes.

[RedBearAK]

Speaking of global menus, I'm not immediately seeing what is different between Enso OS and eOS. They seem to have the same Gala interface with the bar at the top. By "global menus" you mean the menu bar for each application always being at the tope of the screen like in macOS or Unity, right? I feel the same way about eOS missing out on having a proper Mac-like menu bar. Such a waste of valuable screen space.

No luck on commenting out the line in xkeysnail.service. Still doesn't work in IceWM and crashes in XFCE too until I uncomment it.

Call me crazy but coding for the X display port reliably seems like something someone would have found a generic solution for many years ago. And why the heck does it work for XFCE when it says ":0" in xkeysnail.service and XFCE is on ":0.0", while IceWM is on ":0" and it doesn't work? That's a weird one.

[rbreaves]

Enso OS actually uses XFCE as the window manager and to handle the top menu bar, it does not use the wingpanel by the elementaryOS team.. thus it supports Global Menus whereas the wingpanel won't. People did create a super wingpanel in the past to give it global menus but no one is around today that wants to continue to support that fork sadly.

The main thing Enso OS keeps is Gala for Virtual desktops and the slingshot menu which is a fork of a fork lol.

And yea.. I don't understand how to know when it is ok and not ok to manually specify the Display part. I wish I did know, I know it hurts less to specify than to not though. If you want to give me the error log for xkeysnail though you can and maybe I can spot the issue.

The command to do so is the following and the -b will limit the log to only show the current boot session.

sudo journalctl --unit=xkeysnail.service -b

[RedBearAK]

Ah, I forgot that's called the wingpanel. I'll have to try this Enso OS. Wonder if it will support Apple's wifi and bluetooth hardware as well as eOS. eOS has worked splendidly so far on two 2007 iMacs, a 2007 MacBook and a 2011 MacBook Pro, hardware-wise. But if there's something better with a more Mac-like menu bar that doesn't waste so much vertical screen space I'll be all over it, especially on the MacBook with its tiny screen.

I wish they didn't have the window controls on the "wrong" side, but I think that's easily fixed.

Here is the output from journalctl. The errors seem a bit too vague in this output to be very helpful.

journalctl-output.txt

[RedBearAK]

I modified the xkeysnail.service file again and captured the output of journalctl -xe after it wouldn't restart. Seems unusually large.

Oh, right, because it's the entire journal. Nevermind.

I was trying to capture a more useful error message from systemctl but I guess that's all there is.

journalctl-xe-output.txt

[RedBearAK]

I'm going to edit the very first comment to summarize the answers we've discovered in this thread that led to me being able to fix Kinto, at least in XFCE.

[rbreaves]

Yea.. it sorta looks like the xhost command is not running against your x11 session display port correctly for one reason another.. whether it is specified or left blank I am seeing this, now granted if it isn't set to being the same as what you get when you run echo $DISPLAY then that would make sense, otherwise I do not know why that command would fail.

/usr/bin/xhost: unable to open display ":0" /usr/bin/xhost: unable to open display ""

Specifically this command is failing.

xhost  +SI:localuser:root

I would run that individually and see what happens, as well as anything else that runs as part of that service leading up to the final command that needs to run.

/sbin/runuser -l {username} -c /home/{username}/.config/kinto/prexk.sh

replace {username} with your username, no brackets.

And instead of this.. I would just do it more direct

~/.config/kinto/xkeystart.sh /tmp/kinto/xkeysnail/kinto.py

Do this

xkeysnail ~/.config/kinto/kinto.py

xkeystart.sh was intended as a fix for caret checking, something that I have left disabled for awhile as I don't have a fix for back button shortcuts in browsers yet still. (it is in the xkb implementation - but I no longer update it with the latest keymaps.)

[rbreaves]

More info about the xhost command can be seen here and their forums might even provide solutions as well.

https://github.com/mooz/xkeysnail

[RedBearAK]

I'll try to get on that tomorrow maybe. Thanks for all your help with this issue.

It re-occurs to me that the RPi had the right lines in kinto.py uncommented already. Which means that although part of the solution was the same, it's sort of a different problem between the two machines. Well, maybe the same problem, in the sense that both machines had to have the Alt-Tab shortcut manually changed in the Window Manager app. Why would that be, if the correct xfce4 lines were already uncommented on the RPi? Something to think about.

Thanks again for making Kinto. It helps me keep my sanity while using Linux.

[rbreaves]

Honestly I think XFCE not setting that specific combo correctly during install is just a bug of XFCE of some kind - the code to set it is clearly in the ./setup.py file if you inspect it and I even confirmed that it does indeed run like it should... it just doesn't take for some reason or always take.. not sure of the cause.

I can confirm that I am aware of it happening on my chromebooks specifically running GalliumOS with XFCE.. I just kinda hoped others would not have had the same issue or that I was imagining it. I guess I should add a warning during the setup for people to manually set it out of caution on xfce or figure out the issue.

Gnome has a similar bug, in that it was losing all of the shortcuts after a reboot, but I figured out a work around that made the changes stick even after a reboot - but that bug existed for a number of versions of Kinto that I wish it hadn't and afaik it even went unreported I think lol.

Starts on line 170 btw and see # Reset App Cycle

xfconf-query --channel xfce4-keyboard-shortcuts --property "/xfwm4/custom/<Primary>backslash" --create --type string --set "cycle_windows_key"

        elif (distro == "galliumos" and dename == "xfce") or (distro == "ubuntu" and dename == "xfce"):
            print("Applying GalliumOS (xfce) shortcuts...")
            cmdline('cp ~/.config/xfce4/xfconf/xfce-perchannel-xml/xfce4-keyboard-shortcuts.xml ./xfce4-keyboard-shortcuts_`date +"%Y.%m.%d-%s"`.xml')
            # Reset Show desktop
            cmdline('xfconf-query --channel xfce4-keyboard-shortcuts --property "/xfwm4/custom/<Primary><Alt>d" --reset')
            cmdline('xfconf-query --channel xfce4-keyboard-shortcuts --property "/xfwm4/custom/<Super>d" --create --type string --set "show_desktop_key"')
# Reset App Cycle
            cmdline('xfconf-query --channel xfce4-keyboard-shortcuts --property "/xfwm4/custom/<Alt>Tab" --reset')
            cmdline('xfconf-query --channel xfce4-keyboard-shortcuts --property "/xfwm4/custom/<Alt><Shift>Tab" --reset')
            cmdline('xfconf-query --channel xfce4-keyboard-shortcuts --property "/xfwm4/custom/<Primary>backslash" --create --type string --set "cycle_windows_key"')
            cmdline('xfconf-query --channel xfce4-keyboard-shortcuts --property "/xfwm4/custom/<Primary><Shift>backslash" --create --type string --set "cycle_reverse_windows_key"')
            # cmdline('xfconf-query --channel xfce4-keyboard-shortcuts --property "/xfwm4/custom/<Super>h" --create --type string --set "hide_window_key"')
            # Don't need to undo other maps for menu
            cmdline('xfconf-query --channel xfce4-keyboard-shortcuts --property "/commands/custom/<Primary>space" --create --type string --set "xfce4-popup-whiskermenu"')
            cmdline('xfconf-query --channel xfce4-keyboard-shortcuts --property "/commands/custom/<Primary><Shift>space" --create --type string --set "xfce4-popup-whiskermenu"')
            # Reset move to desktop shortcuts
            cmdline('xfconf-query --channel xfce4-keyboard-shortcuts --property "/xfwm4/custom/<Primary><Alt>Home" --reset')
            cmdline('xfconf-query --channel xfce4-keyboard-shortcuts --property "/xfwm4/custom/<Primary><Alt>End" --reset')
            cmdline('xfconf-query --channel xfce4-keyboard-shortcuts --property "/xfwm4/custom/<Primary><Alt>Left" --reset')
            cmdline('xfconf-query --channel xfce4-keyboard-shortcuts --property "/xfwm4/custom/<Primary><Alt>Right" --reset')
            os.system('xfconf-query --channel xfce4-keyboard-shortcuts --property "/xfwm4/custom/<Primary><Alt>Left" --create --type string --set "move_window_prev_workspace_key"')
            os.system('xfconf-query --channel xfce4-keyboard-shortcuts --property "/xfwm4/custom/<Primary><Alt>Right" --create --type string --set "move_window_next_workspace_key"')
            # Reset Change Workspace
            cmdline('xfconf-query --channel xfce4-keyboard-shortcuts --property "/xfwm4/custom/<Primary><Alt>Left" --reset')
            cmdline('xfconf-query --channel xfce4-keyboard-shortcuts --property "/xfwm4/custom/<Primary><Alt>Right" --reset')
            cmdline('xfconf-query --channel xfce4-keyboard-shortcuts --property "/xfwm4/custom/<Super>Left" --create --type string --set "left_workspace_key"')
            cmdline('xfconf-query --channel xfce4-keyboard-shortcuts --property "/xfwm4/custom/<Super>Right" --create --type string --set "right_workspace_key"')
            print("\nYou may need to run these commands manually to make sure they are set, if you want to move windows between desktops.\n")
            print('     xfconf-query --channel xfce4-keyboard-shortcuts --property "/xfwm4/custom/<Primary><Alt>Left" --create --type string --set "move_window_prev_workspace_key"')
            print('     xfconf-query --channel xfce4-keyboard-shortcuts --property "/xfwm4/custom/<Primary><Alt>Right" --create --type string --set "move_window_next_workspace_key"\n')

[RedBearAK]

Yeah, I saw those lines in setup.py. Guess it's not your imagination anymore, eh? Definitely something weird going on.

If I were to "break" my Alt-Tab again and then run this command, that should theoretically fix it?

xfconf-query --channel xfce4-keyboard-shortcuts --property "/xfwm4/custom/<Primary>backslash" --create --type string --set "cycle_windows_key"

[rbreaves]

Probably would fix it if you run the command manually, but setting it via the GUI should definitely work if the command doesn't lol. I do recall also seeing it mapped but not actually working at least 2 or 3 times on my chromebook and just having to reset it via the GUI as well.

Weird behaviors for sure, reminds me of KDE in some ways as I would sometimes just have to log off and back on to get KDE to work right, even restarting the KDE DE via the terminal wasn't always enough until I logging out and back in.

Main reason why I prefer Gnome3, Budgie or Mate these days.. even though Gnome3 lacks global menus and has a hotkey persistence bug that I had to find a workaround for and did.. the settings I set for those DEs tend to stick very well and with the least amount of fuss, XFCE behind them and KDE is dead last. I hate that because normally I like KDE. The issue with KDE is that it is the most difficult to automate successfully without asking the user to logoff and back on.

Also I just hate the sheer number of options it has - it is great in one sense and horrible in another, KDE has too many options spread out all over the place - it is getting about like Windows 10 in having too many menus and places to set things and potentially some areas that work better than others.