Kinto fails on 32-bit MX Linux (with or without systemd)

[RedBearAK]

Describe the bug
Tried to setup Kinto on a very old (2002-ish Pentium 4, 2.4GHz with 1GB RAM) laptop that I have running 32-bit MX Linux 19.2 (latest release of MX as of a few days ago). There are systemd and non-systemd variants of the kernel. I've tried both. I've tried the xkeysnail and the x11 version if the Kinto setup. No matter what options I choose Kinto doesn't seem to be doing any keyboard or shortcut remapping.

I used "tee" to output the text of my attempts to install both with and without systemd on the same computer. See the two text files below. There are errors during setup in both cases.

kinto_output_systemd.txt
kinto_output.txt

Install Type: Bare Metal
Distro: MX Linux 19.2
DE: XFCE, IceWM
Branch: master

[ Editing to add solution found in this thread: ]

Somehow pip3 fails to install three necessary python3 packages (needed for compiling xkeysnail during install?). To bypass on MX Linux until the bug is resolved, run this command before running ./setup.py:

sudo apt install python3-setuptools python3-wheel python3-dev

(Turns out python3-dev is needed on a new MX Linux install.)

[rbreaves]

I don't think my install script knows how to install python3 and pip on your system is the most probable issue. Once you resolve that you should be able to run kinto manually, even if you can't run it via systemd.

ModuleNotFoundError: No module named 'setuptools'

manually running kinto should be as simple as

xhost +SI:localuser:root
sudo xkeysnail ~/.config/kinto/kinto.py

Main reason I use systemd is that it helps keep it running and I have extra things in there too to help initialize it properly or refresh it if the config changes (although changing the config in real time is not something I currently do for reasons I won't go into).

[rbreaves]

I am also open to accepting PR's from anyone that wants to add non-systemd support to Kinto, it just isn't something I am able to test atm or have an interest in since most major distributions appear to be using systemd these days (granted differing systemd versions could create issues under some circumstances so even that has to be tested against carefully).

[RedBearAK]

I am also open to accepting PR's from anyone that wants to add non-systemd support to Kinto, it just isn't something I am able to test atm or have an interest in since most major distributions appear to be using systemd these days (granted differing systemd versions could create issues under some circumstances so even that has to be tested against carefully).

MX Linux is number 1 at the moment on DistroWatch, and it's based on antiX which is systemd free. I think you might be underestimating the number of Linux users who still aren't using systemd, and never will. I would strongly encourage you to make Kinto more portable. I would really love to be able to run Kinto on any non-Mac system I ever have to touch.

[rbreaves]

Distrowatch isn't necessarily representative of which distros have the largest userbase/mindshare, but point taken still. I did play around with one distro based on mx linux awhile back, but it was so heavily modified it wasn't a very good experience. I can't blame mx linux, I was looking for something rather specific and bloat wasn't my biggest concern lol.

I don't mind looking into MX Linux at a later date, part of the issue with linux in general is the sheer number of variations out there, and any help from the community is greatly appreciated and I am more than happy to merge PR's. Offering non-systemd support really should not be that difficult at all considering that all it would really take is the right startup script in the right place running these 2 commands. May also need to bring over the limitedadmins file my installer sets up as well to ensure that xkeysnail can run with sudo privileges automatically.

xhost +SI:localuser:root
sudo xkeysnail ~/.config/kinto/kinto.py

Of course until I or someone implements it I have no way of knowing with 100% certainty that that is all that it would take. Also it would be ideal to start the script in a way that would keep it always running unless explicitly killed by the user.

[RedBearAK]

I tried the commands you offered. The first (xhost) works of course, the second command fails with "xkeysnail: command not found".

However, the xkeysnail service is running (when I do the Kinto install with the systemd kernel). But the problem remains that no key remapping appears to be happening. Can the service be running while the xkeysnail binary doesn't exist on the system? Or is it just maybe not showing up in the path? A "whereis xkeysnail" returns no result.

Since MX appears to be just Debian Stable, as that is what MEPIS and antiX are/were based on, and it is pulling from Debian Buster repos, you can color me very confused as to why this isn't working.

I also checked and the python3 and python3-pip packages are both already installed and latest versions, although I'm not entirely sure if they were installed with the base MX system or were installed the very first time I tried to run the Kinto setup script. It was a while ago.

Versions:
python3 (3.7.3-1)
python3-pip (18.1-5)

So the main issue at the moment seems to be this pip error and the "no module named setuptools". How can I troubleshoot that further?

[rbreaves]

pip install setuptools
or
pip3 install setuptools

Also if you want to install xkeysnail manually then you could try my fork of it, although the last two commits are duds so I have the script doing this atm.

git clone --depth 10 https://github.com/rbreaves/xkeysnail.git
cd xkeysnail
git checkout 51c369084e0045a8410d227bab52411bf84fb65b
sudo pip3 install --upgrade .

xkeysnail has no ability or option to install as a systemd service or a service of any kind by default so that stuff was written by me. If you want to see how people, if anyone handles starting xkeysnail on non-systemd, systems then I suggest you take a look at the source https://github.com/mooz/xkeysnail.

My work for the systemd service is based on a combination of what those users suggested and what I was already doing and what I found that worked best for this particular setup.

[RedBearAK]

I want to try to fix Kinto so more people can enjoy Kinto.

Tried the pip3 install command, worked fine. Still get exactly the same error from the "python setup.py egg_info".

What else would you try if you were encountering this? Is there like a test python script that verifies the pip setup or something? Any ideas?

[rbreaves]

I am not sure, can you post your full error log again? Does it still mention the setuptools part or has that gone away?

Maybe this threads suggestions could be relevant?

googleapis/google-cloud-python#3884

sudo pip install --upgrade setuptools
sudo apt-get install python3.6-dev

Although I'd probably suggest install this other python dev package under Ubuntu or Debian

sudo apt install python3-dev

[RedBearAK]

Oh, this is interesting. I tried running the pip install stuff with sudo because I noticed that it was installing the tools in a ".lib" folder in my home folder.

Now Kinto starts doing a number of things including some downloading, and then KABLOOEY, it breaks again.

LOL. I started typing this before even seeing your latest message about using sudo. That's funny. I'll try to install the dev stuff.

[RedBearAK]

Wow. Even with the still broken install process, Kinto starting working! Here's what I had to do to completely fix it and get through the whole installer script without an apparent error.

sudo pip3 install setuptools
sudo pip3 install wheel

Not sure if the python3-dev was necessary, but that was at least the correct command to install that package on MX. The wheel install was definitely necessary as the script was complaining about "bdist_wheel" being missing.

So now we just need to figure out why Kinto fails to install properly on a Debian-based distro when it installs fine on other Debian-based distros like Ubuntu, eOS, Rasbian/Twister OS. No idea.

But now here is the remaining problem, again, Alt-Tabbing between windows has moved to Win-Tab. [insert sad face here]

[rbreaves]

But now here is the remaining problem, again, Alt-Tabbing between windows has moved to Win-Tab.

I commented about it in the other thread.. had a really long post initially before just deleting it all. Pretty sure I probably just assumed the Apple HID driver was available & thus Kinto ends up doing a keymap that can't possibly work on an Apple keyboard without the HID driver present.

All I am saying is pick option # 2 during the Apple keyboard setup and you will probably be off to the races lol. It does line up correctly with macOS, but I guess I need to be checking for the driver's existence instead of just assuming it is there.

[RedBearAK]

Before I leave this thread I just want to note that this whole time the Kinto installer script was totally ignoring the fact that all the subprocesses were reporting major failure errors. It kept telling me at the end, in bright green happy letters, that "Kinto is installed".

[rbreaves]

Yea lol.. thanks for the feedback.. all those green letters really indicate is that the service itself started up - not that it is necessarily working. In most cases, and at the time of its creation, I assumed that the service couldn't possibly be in a running state if some part of the install had failed.

Clearly my assumption was not valid if the green letters appear and the service runs, but Kinto is not functioning. Additional checks do need to be added - one that verifies that xkeysnail installed properly & if it doesn't then end the install attempt and another to verify that the Apple HID driver exists before allowing the user to select the 1st option on the mac keyboard setup.

[RedBearAK]

Can confirm that the python3-dev package doesn't appear to be needed to fix the problem of setup failing on MX Linux. Setup.py completed with no errors even after removing python3-dev.

Also, editing setup.py to include a test for debian/xfce on the same line where it already tests for gallium/xfce and ubuntu/xfce combos results in Kinto successfully applying the proper Cycle windows shortcut. This is after using the XFCE Window Manager to change the Cycle windows shortcut back to showing "At+Tab". After re-running setup.py with these mods, window cycling is back to showing "Ctrl+Backslash" and "Shift+Ctrl+Backslash" (reverse), and is properly assigned to the physical Alt-Tab key combo.

So this means the commands in setup.py work fine, at least on this MX 19.2 system, in XFCE, as long as they get triggered.

Maybe don't be so strict about matching the distro if you detect xfce? I would have to edit that line and add yet another test for "raspbian/xfce" to make this work on a Raspberry Pi, since that is how setup.py detects Twister OS and probably everything else based on Raspbian.

Also might want to think about Kinto being able to use different settings on-the-fly when the user moves from one DE to another. As many of us do. Obviously I'm referencing the problem where Kinto breaks when moving from XFCE to IceWM.

I'll be editing the first post to add the "pip3 install" commands that solved the main issue that started the thread. The remaining question is why those pip packages weren't successfully installed in the first place. I wonder if my machine was just offline right when I first tried to run setup.py. I've had issues with my PC card wifi not being reliably activated at boot. Still, if that is the problem then setup.py should recognize the failure to install setuptools and whell and stop at that point.

[rbreaves]

Yea I probably should just allow xfce, I guess initially I wanted to limit support issues to the distros I had tested, but I imagine it'll work pretty well in most cases.

I am making some updates now to improve things on Budgie a little and to speed up the installer so it doesn't slow down on the Apple keyboard setup when no apple keyboard is present. Also if a user does the regular Mac Only setup after doing the HID driver setup it will remove the HID driver cmd swap as that could cause issues unless the person runs the uninstall.. but that is a step that is unnecessary when it can install on top of itself properly.

[rbreaves]

An update has been merged into master now that will allow for xfce on any distro.

[RedBearAK]

An update has been merged into master now that will allow for xfce on any distro.

I’m not too familiar with how GitHub works. Does “merged into master” mean that if I re-cloned the kinto folder right now that change would already be in there even without a new version number?

[RedBearAK]

Just "broke" Kinto on my RPi4 (uninstalled and also made sure to manually reset the XFCE shortcuts with Window Manager, putting everything back to defaults). Re-cloned Kinto and re-ran setup.

XFCE systel level shortcuts were successfully applied by the setup script at the end of install with no complaint about "no matching distro and DE found", and as expected I did not need to manually change the Cycle windows shortcut on the RPi4 with Twister OS/Raspbian. So the problem here was really just that Kinto didn't set the system level shortcuts because of the "unknown" distro name. With that check being more lax, all the common shortcuts including Alt-Tab appear to work perfectly after install. Forgot to close the Window Manager app, but now it does show "Ctrl+Backslash" where it said "Alt+Tab" before Kinto reinstall.

Great job.

[rbreaves]

Good deal, I will close the other thread and I suppose I will keep this one open until I added the additional pip packages you mentioned. I wonder if those are like default packages that get installed on other distros or something..

[RedBearAK]

I am planning to do all this to clean out the MX machine and see what happens when I attempt to run setup.py again.

sudo pip3 uninstall setuptools
sudo pip3 uninstall wheel
sudo apt remove pip
sudo apt remove python3

It's my understanding that setup.py should attempt to install all of this on its own.

[RedBearAK]

Can confirm that the keyboard shortcuts don't get reset to defaults by the Kinto uninstall script on this MX machine. Also tried the new git clone of master. Resetting to defaults manually.

[rbreaves]

well setup.py runs xkeysnail_service.sh which then installs some pip related packages, but not wheel or setuptools specifically. Linux-mint was known to need setup tools, but I will need to know what the distro name is of mx linux according to the script to add it and wheel, if needed.

Run this command so I can add MX Linux to the list and add those 2 packages, then the xkeysnail package I would imagine will compile and install properly on your system for Kinto to work.

awk -F= '$1=="NAME" { print $2 ;}' /etc/os-release

[RedBearAK]

The pip packages seem to be python-pip and python3-pip, not just "pip". So I'll uninstall those.

[RedBearAK]

A lot of other packages would be removed with the main python3 package, and would setup.py even run without it? I'm guessing no. So not removing that.

[rbreaves]

umm yea the setup file won't run without python3 being installed at a bare minimum. Most distros already have python3 installed I believe, but it is mentioned in the readme.

I mean I guess I could switch to a shell file that could handle installing python3 too if needed lol, there's already a mix of shell/bash and python files.

[RedBearAK]

OK, so we're back to the "egg_info" error, but nevertheless the script completes and Kinto appears to be working, including the Alt-Tab function. Probably because the XFCE system level shortcuts are applied with the new Kinto commits.

The setup paused long enough during install that I was able to notice something about additional python3 packages that were "recommended" but weren't being installed:

The following packages were automatically installed and are no longer required:
libexpat1-dev libpython3-dev libpython3.7-dev python3.7-dev
Use 'sudo apt autoremove' to remove them.
Recommended packages:
python3-dev python3-setuptools python3-wheel
The following NEW packages will be installed:
python3-pip
0 upgraded, 1 newly installed, 0 to remove and 3 not upgraded.

Guessing that installing python3-setuptools and python3-wheel will do the same thing as "pip3 install setuptools" and "pip3 install wheel". I'll try it.

Are these parts of python not broken out into separate packages on your distro?

[rbreaves]

this is the logic in the xkeysnail_service.sh file. It mostly just installs the dev package, but only the setuptools in one distro. Wheel isn't in there are at all. Every distro differs slightly though, so not surprising mx linux would need different things imo. It may not even share the exact same debian or ubuntu based repos for all I know.

	if ! [ -x "$(command -v pip3)" ]; then
		echo "Will need to install python3-pip..."
		sudo ./system-config/unipkg.sh python3-pip
	fi
	if ! [ -x "$(command -v python3-config)" ]; then
		if [ "$distro" == "ubuntu" ] || [ "$distro" == "debian" ] || [ "$distro" == '"linux mint"' ]; then
			pydev="python3-dev"
		elif [ "$distro" == "fedora" ]; then
			pydev="python3-devel"
		fi
		if [ "$distro" == "gnome" ] || [ "$distro" == "fedora" ] || [ "$distro" == "debian" ] || [ "$distro" == '"linux mint"' ]; then
			echo "Will need to install $pydev..."
			sudo ./system-config/unipkg.sh "$pydev"
		fi
	fi
	if ! [ -x "$(command -v xhost)" ] || ! [ -x "$(command -v gcc)" ]; then
		if [ "$distro" == "\"manjaro linux\"" ]; then
			sudo ./system-config/unipkg.sh "xorg-xhost gcc"
		fi
	fi
	if [ "$distro" == '"linux mint"' ]; then
		pip3 install setuptools
	fi

[RedBearAK]

No apparent errors when running setup.py after installing python3-setuptools and python3-wheel packages.

It strikes me that since Kinto seems to work immediately after setup even when the script encounters errors (before installing the above packages), I never would have noticed this problem with the current iteration of Kinto.

Anyway, so setup.py seems to (at the moment) still be failing to install python3-setuptools and python3-wheel on MX Linux 19.2. Only python3-pip is installed automatically.

I think I'm at my troubleshooting limit here. I guess the remaining thing is to keep trying to fix Kinto under IceWM, but I'm not sure where to go with that.

[rbreaves]

It's super annoying that different distros split up their packages differently and give them different > names, but isn't there a way to tell apt that you need specific files/libraries and then apt will just > > kind of figure out which packages contain those files? Which could work much more universally > > on all distros, and even under other package managers like yum, or yaourt or rpm. Or is this some > pie-in-the-sky fantasy?

Pie in the sky indeed lol. Part of the deal with creating a distro is having maintainers and your own repos. There can be official branch distros based off the major distros of course, and apparently mx linux is that, but a Debian off shoot and I can't say I have done a lot of testing on Debian. I did spin up a Debian VM a long while back just to make sure I was supporting the main distro. I do recall some setup issues in the VM unrelated to Kinto.. but I must have had it working otherwise I wouldn't add it to the readme. I don't currently have the VM on my system though.

Ubuntu on the other hand has had much more extensive testing, it and its many offshoots.

The official list of distros I have tested against and know I can support is on the readme page.

• Manjaro/Arch/Debian/Ubuntu based distro 16.04+
• Fedora/RHEL (may not work w/ xkeysnail, but original xkb version does)

Looking at my setup file though there is no mention of Debian being listed to get any DE related shortcuts applied, of course XFCE will get them regardless now, but Debian with Gnome would not get the Gnome system level shortcuts applied unless I add it to the list.

The other xkeysnail setup file though does mention Debian and is supposed to install python dev, but it won't do that if the full os release string is coming back instead of just Debian.

[RedBearAK]

Twister OS on RPi4 spits out this for the awk command:

"Raspbian GNU/Linux"

Doing this reminds me that my Alt-based X/C/V keys, and select all and probably many other things, are working the same in the terminal here as they do in the browser. However that doesn't happen on MX Linux. Is this a bug with Kinto not detecting the terminal app properly?

Personally I would much rather have the Mac-style keyboard shortcuts also working in the terminal. Not sure why it's so important to change everything when going into a terminal. Is that for people who use things like vi and emacs?

[rbreaves]

Interesting, although Raspbian stuff probably has python3 in it up the wazoo lol.

And honestly my 3 concerns were the few system level shortcuts I use daily, like Cmd-Space and the whole Alt-Tab thing, my favorite sublime text 3 shortcuts and yes the terminal stuff - copy, paste, end prorgram, etc.

A lot of what is in Kinto now fully exceeds what I needed personally, but for completeness sake I have fully remapped sublime text 3 on the Linux side (about to do the same on the Windows side but still haven't - and no one has even complained lol.. but a few are in there, the ones I use daily.). I had no intention on moving to Windows 10, but here I am on it lol.

Kinto to me is also a platform for others to jump off of - I want them to trust that I have the got the system level, base level stuff taken care of completely and that if they want to use it then the most they MIGHT have to do is add a few shortcuts that are truly, and wildly different btwn macOS and Windows or Linux. Beyond that most things should just work out of the gate - and that is how I want it. Dying of a thousand paper cuts like some people might that are trying to just tackle each and every individual keymap per an app is insanity.

With Kinto you fix the few things that get missed here and there - an app will never need a 100% complete remap to be fully remapped. You MIGHT remap like 10% or less of the shortcuts and most of that just comes from OS design philosophy differences that cause a few genuine conflicts - like some Windows app using Ctrl-Q to do a specific function where macOS uses Ctrl-Q to quit apps universally so uses some other keybinding for that function.

[RedBearAK]

Yes, Windows continues to be insidious and difficult to stay away from. At least it has a nice Linux subsystem these days. Have you done the 2004 update? It is supposed to bring significant improvements to WSL.

The terminals I'm using on both MX and Twister OS appear to be xfce4-terminal. So not sure why it doesn't get the special treatment on the RPi4.

But I would like a pointer on how to disable the special treatment of terminals, because I don't use any of those special key commands. Should just need to comment something out in setup.py, right?

[RedBearAK]

I'm VNCing into my RPi4 and noticed that the Kinto remaps don't seem to work via this interface. To reload the page I have to do Ctrl-R. I'm VNCing in from a Mac running Mojave via the official RealVNC VNC Viewer 6.20 software.

Would you consider this normal and not fixable?

[RedBearAK]

I've never really tested it much, but Alt-Space opens the application menu on XFCE on the MX system. On the RPi4/Twister OS it doesn't seem to do anything. Win-Space opens the window controls context menu, where all the minimize/maximize stuff is. I guess that would be "Alt+Space" in Window Manager, and it says that's assigned to "Window operations menu". So that seems right.

What is it exactly you expect Alt-Space (Cmd-Space) to do on other distros and DEs where there may not be a Spotlight-like interface? What is the (hopefully) standard name of the system shortcut that Kinto tries to activate with Alt-Space? I just scanned through Window Manager on the RPi4 and didn't see any reference to anything like "Applications Menu" or similar.

[rbreaves]

I can’t give blanket advice unfortunately w/ remote or even VM situations. Some experimentation will be required, it’s possible to fix it on either the client or host, it’s mostly your preference.

It’ll be A LOT simpler to fix once I implement the tray menu where you can quickly try out all of the keyboard types or suspend Kinto w/ a single click.

In general the remote situation, host or client, should work better w/ the xkeysnail implementation than the xkb solution. I have not done any tests w/ VNC though.

Terminals in the keymap are very simple to disable.. just give it a blank array I guess [] at the top or yea comment out all references to the 2 Terminal groups referenced at the top. Honestly I think that’s like the best part of macOS so I’m surprised you’d want to get rid of that, but keep the other stuff lol.

[rbreaves]

Concerning system level shortcuts like Cmd-Space please reference #44 most, if not all, system level shortcuts supported are listed there & their intended function.

I don’t want to be opinionated on what spotlight apps people ought to use, my preference is Alfred, but for the sake of the project I use as few 3rd party apps as possible & make use of default analogs in every instance that I can. Part of the issue w/ relaxing the distro requirement of xfce is that I can’t ensure a good user experience & I could introduce conflicting keybinds into the system level shortcuts.

That’s why I created #44 to help me clearly define what system level shortcuts I can support across all DEs & distros that I wanted to support. DE defaults get changed all the time & of course I could support more in one than another but I tend to only change things that I can change in bulk so the user experience will remain the same in any distro, at least that’s the goal.

[RedBearAK]

Not quite sure what you're referring to with "the best part of macOS" but I do know that in macOS I can Alt-C something in one app and then step into the Terminal app and Alt-V to paste, and vice versa. Here on Linux even with Kinto I keep having to remember to Alt-C in one app and then Ctrl-Shift-V when I switch to the terminal. It's annoying. That's mainly what I'm talking about.

Although, strangely, Alt-V and Alt-C are working in the terminal right now, while I'm in IceWM. Confusing.

Funny story, logging out of XFCE and back into IceWM obviously still breaks Kinto. But re-running setup.py results in a working Kinto once again. In IceWM. Just like before we fixed the Win-Tab mapping in XFCE.

So it appears to be absolutely possible to have Kinto working in IceWM, just like it was originally. I just have to find a way to remap the correct window switching key under IceWM and it will be perfect. Then the remaining issue is how or why I have to re-run setup.py after switching from one DE to the other, and if there is a way to overcome that problem.

IceWM is identified as "unknown" by setup.py, so no system level shortcuts are applied.

I even tried restarting the xkeysnail service while running IceWM. Works fine.

Soooo.... This is a problem where going from one X display port number to another trips Kinto up, but reinstalling fixes it? No idea why that would even work.

[rbreaves]

Here on Linux even with Kinto I keep having to remember to Alt-C in one app and then Ctrl-Shift-V when I switch to the terminal. It's annoying.

Well you keep assuming that Kinto is behind that I guess?.. it’s not. Kinto might lack your specific Terminal app.. which you can discover the programmatic name of via xprop -spy or by searching past tickets that had unsupported terminals which were added by me or even PR’s by some individuals that helped add additional terminal names.

Terminals in Linux tend to use very standardized shortcuts so just adding the name at the top of Kinto.py in the terminal array is all you need to do 99% of the time. I even fixed it so it’s case insensitive too.

From the way you were talking I thought you wanted to remove the dynamic keybinding on all terminals lol.

tldr It’s not Kinto failing, it just doesn’t have your terminal’s in the config file.All terminal names supported are literally at the very top of the ~/.config/kinto/kinto.py file & can easily be amended.

[rbreaves]

The solution to changing keyboards or de’s will be the same once the system tray is built, unless triggers are added to existing scripts associated w/ the DE’s or new usb devices triggering a script to auto set the keyboard.

These are all things that can be implemented but I can’t give an ETA on any of it right now. It’s in the roadmap though.

I would like to do both, manual & auto resetting of key install options & it’d be very fast. Due to Perl regex & the simple commented structure in a single config file things can easily be changed post install & reloaded. Part of the design.

[RedBearAK]

Update. Kinto also fails when simply logging out of IceWM (I think this distro uses lightdm for the login greeter?) and back into IceWM, with no XFCE in between. Re-running setup continues to fix Kinto in IceWM. So the setup script is correctly initiating something which then breaks when logging out or when logging back in.

I found the way to edit the keyboard shortcuts for IceWM, a text file located at ~/.icewm/preferences. Fortunately it already existed and was pre-populated with helpful text. The key for task switching appears to be called KeySysSwitchNext and is set to "Alt+Tab" by default.

Unfortunately I have tried KeySysSwitchNext="Ctrl+XF86Tools" (as reported by xbindkeys when I press Alt-Tab) as well as "Ctrl+Backslash" and "Ctrl+F13" and after trying "Ctrl+Tools" I will be out of ideas. Nothing has worked so far. But it definitely breaks the standard Alt-Tab shortcut (on Win-Tab), so it's doing something.

I plan to keep at this until finding the solution. Tomorrow.

[RedBearAK]

I'm so braindead I forgot all about trying that xhost command you mentioned before. After running that I can do "sudo systemctl restart xkeysnail" and Kinto works right away. In IceWM. No re-running setup.py.

Now the only remaining issue is finding what key names to put into the IceWM preferences file to get Alt-Tab working, as in the previous post. And maybe find what Cmd-Space should be attached to, or if I can use that to launch an app like Alfred. Had trouble getting Alfred to run here but I have a tiny app called grun that at least lets me launch some apps by name.

Later.

[RedBearAK]

I left Kinto set up with the XFCE system level shortcuts in XFCE, then went back to IceWM, without redoing Kinto setup. Tried "xbindkeys -k" again with the XFCE system level shortcuts active, and this time it said Alt-Tab was "Ctrl+backslash" (note no capitable "B").

Tried putting KeySysSwitchNext="Ctrl+backslash" this time in the IceWM preferences file instead of "Ctrl+Backslash", which didn't work.

Used the xhost command and restarted xkeysnail.service, then restarted IceWM.

Interestingly, there is a command in the IceWM logout menu to just restart IceWM without actually logging out or needing to close any application windows. It takes less than a second and doesn't break Kinto. They probably desperately needed this functionality because you basically have to edit text files to change pretty much anything in IceWM.

I now have a fully functioning Kinto as well as window switching (Cycle windows) on the physical Alt-Tab keys with the "Ctrl+backslash" code. Just now reconfirmed that it does not work with "Ctrl+Backslash" with the capital "B". Picky, picky.

Going back to XFCE requires no further actions to keep Kinto working at this point. Only when logging into IceWM.

So in the end, all I have to do (LOL) is run a script that does the commands below every time I log into IceWM, and everything starts working again:

xhost +SI:localuser:root
sudo systemctl restart xkeysnail

If you want me to run any further commands to try and nail down why xhost seems to be failing to work automatically when logging into IceWM, and therefore how to stop this issue in a future Kinto release, I'm available. At this point the permanent solution seems like it might be pretty simple if we can just catch exactly what xhost is tripping on.

[rbreaves]

It's not a particularly high thing on my list, never even heard of IceWM before you mentioned it lol.

If you do figure it out and send a PR I will review it and possibly merge it however.

The issue imo is most likely due to how IceWM interacts with systemd, it is surprising that simply restarting the service is not enough, that you also have to manually run that xhost command in your user session. Not to say I did not have xhost related issues with other distros - I did and I worked them out. Also any potential xhost fix you may find for the systemd service will have to be tested on all existing and supported distros before being approved (there are several that I test against).

The setup file updates the service file in multiple areas, but the relevant one is this one.

sed -i "s#{xhost}#`which xhost`#g" ./xkeysnail-config/xkeysnail.service.new

Service file before the setup updates it

[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

It makes me wonder if you were to change this line here

ExecStartPre=/bin/bash -c "{xhost} +SI:localuser:root && /sbin/runuser -l {username} -c {homedir}/.config/kinto/prexk.sh"

to

ExecStartPre=/bin/bash -c "/sbin/runuser -l {username} -c {xhost} +SI:localuser:root && /sbin/runuser -l {username} -c {homedir}/.config/kinto/prexk.sh"

If that doesn't work then you could also try setting xhost to run without creds in the limitedadmins file that the installer sets up too.

# /etc/sudoers.d/limitedadmins
%{username} ALL=NOPASSWD: {systemctl} restart xkeysnail
%{username} ALL=NOPASSWD: {systemctl} start xkeysnail
%{username} ALL=NOPASSWD: {systemctl} stop xkeysnail
%{username} ALL=NOPASSWD: {systemctl} status xkeysnail
%{username} ALL=NOPASSWD: {xhost}
%{username} ALL=NOPASSWD: {xhost} +SI:localuser:root

Be careful though.. editing limitedadmins could bork your system - and I have not tested what I posted above - it is intended to be read fully and with the recognition that I do not know your systems variables so you would need to remove {} and the placeholder names with the appropriate ones.

A lot of what I did was done in a way to make the setup more secure - by linking to the actual paths of the binaries and not just their generic names. I will be closing this thread as I don't believe any more immediate actions will be taken. Some of your requests will also be resolved naturally through updates that will be coming regardless (aka switching keyboard layouts quickly (vnc/remote)).

You can continue to update me in thread or do a PR if you decide to fork this project and submit updates.

Also if I add any additional DE/WMs it'll probably be i3 and maybe openbox because they have name recognition with me. (of course it is assuming it doesn't work already, it could and I not even know it.)

[RedBearAK]

Isn't part of the problem the fact that systemd is not recognizing that xkeysnail.service needs to be restarted? Or xkeysnail is not telling systemd that it needs to be restarted?

I don't know if I ever showed the status output from right after logging into IceWM vs after "fixing" Kinto, but in both cases the xkeysnail service is "active", i.e. it still seems to think it's working. It only "crashes" and becomes totally inactive if I don't run the xhost fix before trying to restart the service.

If something could recognize the "Xlib.error.ConnectionClosedError" and then restart the xkeysnail.service, maybe this could be fixed. Or would that still crash unless I manually ran xhost?

Here's the output:

xkeysnail-service-before-fix.txt

xkeysnail-service-after-fix.txt

[RedBearAK]

I logged out of IceWM and went back to the LightDM login screen. then went to a different tty console to check status. I see the same "Xlib.error.ConnectionClosedError". The service crashes when I try to restart it.

I don't know how to echo the $DISPLAY variable of a different console, so I can't check that.

Going back to the LightDM console and logging in to IceWM, the service is still crashed (crashing?). Once I run the xhost fix it immediately comes back up with no errors. I discovered there is no need to manually restart the service. It just suddenly starts working. So at least that part of systemd is working as expected.

I tried the part above where you said to add /sbin/runuser in front of {xhost} in the xkeysnail.service file. It did not appear to make any difference. Still wouldn't work without manually running the xhost command after logging in.

Now proceeding to test editing the /etc/sudoers.d/limitedadmins file.

[RedBearAK]

Visudo and sudo both complain about a syntax error after inserting the line containing "+SI:localuser:root" in limitedadmins. With the first xhost line alone, the xkeysnail service crashes, and even after applying the xhost fix after logging in to IceWM I now have to manually restart the service to get it to come back up.

It's not being specific about the syntax error so I have no idea how to get past that. Tried putting backslashes in front of the plus and colons, of course that didn't work.

[RedBearAK]

After some googling I was able to get the "+SI:localuser:root" line to be accepted by escaping just the colon characters, not the plus.

Has not solved the problem. Still need to run xhost manually after logging into IceWM.

That's the limit of what I can think of to try, again.

[RedBearAK]

I would have loved to help test with other DE/WMs like i3, Openbox, Fluxbox, FLWM, LXDE/LXQt, etc. But I've tried all the ones I could think of that this machine would be capable of running without barfing from lack of RAM, and they were pretty much all broken on this distro. Like, blank screens, generic menus that don't really work, no apparent way to even log out, and so on. Besides the default XFCE desktop, IceWM is the only other desktop that has worked worth a darn on this distro for me. I know this kind of thing often happens when you fail to install the correct metapackage that configures everything for the platform, but I can't find any more "meta" packages for any of these DE/WMs.

I actually used IceWM as my default WM on a distro called LibraNet back around 1999, so it's a bit nostalgic too. So glad I was able to get Kinto working on it.

[rbreaves]

If something could recognize the "Xlib.error.ConnectionClosedError" and then restart the xkeysnail.service, maybe this could be fixed. Or would that still crash unless I manually ran xhost?

That is a bit of an issue tbh. Try replacing this in the xkeysnail.service file

ExecStart=/usr/bin/sudo /bin/bash -c '{experimental-caret}{homedir}/.config/kinto/xkeystart.sh /tmp/kinto/xkeysnail/kinto.py'

with

ExecStart=xkeysnail ~/.config/kinto/kinto.py'

Although you may need to run which xkeysnail and provide the full path and also expand ~ to your actual home directory. It may make systemd handle errors better than it running in that bash shell wrapper.

[RedBearAK]

This works only if both the xkeysnail path and the path to kinto.py are fully expanded. However I still have to run xhost after logging in before Kinto will start working. So, no change really.

[rbreaves]

This works only if both the xkeysnail path and the path to kinto.py are fully expanded. However I still have to run xhost after logging in before Kinto will start working. So, no change really.

Systemd service files do allow for you delay to be added if you want to try adding that. I had a delay at one time, but I thought the necessity of that had gone away fully.

[RedBearAK]

There seem to be various ways of doing a delay with a systemd service. What would be your suggested method? How were you doing it before?

Although I don't see how adding any delay would do anything to address the issue of the service having the Xlib.error.ConnectionClosedError and subsequently crashing if restarted before I manually run the xhost command.

[rbreaves]

Easiest way is probably something like ExecStartPre=/bin/sleep 30; {rest of execstartpre here}

I used the timer service method for xkb keyswap & you could probably make the timer a user level systemd service that starts up the system level xkeysnail service, too much to type how. Install gitk & search timer or look for timer in the source code for xkb or keyswap.service may still use it.

[RedBearAK]

Installed MX 64-bit AHS on a new AMD Ryzen system and discovered that evdev will fail to compile with a missing "Python.h" file unless you also install python3-dev. Updated the solution in the first comment. So MX needs all these packages installed to successfully compile and install Kinto:

python3-wheel
python3-setuptools
python3-dev

Maybe it worked on the other MX system after I removed the python3-dev package because I just used "remove" instead of "purge".