How to make this modification installable?

[probonopd]

Is there a way to make this modification installable in e.g., a deb, so that it could be preinstalled on many systems automatically?

[rbreaves]

I had no plans on creating a deb file, but I don’t see why not as long as I make a proper installer than ensures systemd, xprop & python3 are available.

I will look into this.

[probonopd]

Indeed I am more interested in having the resulting configuration as a deb, not the tool that creates it.

[rbreaves]

I have now released v1.0 and creating a deb would present some challenges, you'd have to "preseed" the deb file with your desired settings since I do not yet have a GUI that lets you change or update the settings after the install. I don't have an eta on this at this time.

All config settings however are in json files now, which will make it much easier to create a GUI app to change settings after the install.

You can also make the install somewhat portable yourself by copying the two directories "/.xkb" and "/.config/kinto" and then run the ./keyswap_service.sh script (w/ ./system-config/ and ./kintox11 folders) to fully install it. I know on Windows you can pretty easily create self extracting exe's, I assume there may be something similar you can do on linux.

[rbreaves]

@probonopd I believe this guy tarzeau or @alexmyczko has made this into a deb package, although you still have to run the setup.py for now. I have not spent the time to create method to preseed it or pass arguments into it to configure it.

At some point I'd like to add a GUI and/or system tray app for the configuration so it can be properly configured after a deb install, but I have no ETA on that atm.

http://phd-sid.ethz.ch/debian/kinto/

[probonopd]

Thanks @rbreaves. Ultimately I'd like this to go into the native settings of Xfce, KDE, GNOME, etc. - maybe contact those projects?

[rbreaves]

I could, I'd probably need to learn to use and get accustom to mailing lists to be honest lol. I have successfully avoided mailing lists thus far in my life.

I am not sure that they would accept my code as something they'd want to integrate directly into their projects or not, however by just talking to the maintainers and devs of those environments it could help me further along the behavior I am trying to replicate. There are also concerns of Wayland and how Kinto will need to change some significant parts of its code to work within Wayland - it will need code that is more DE specific than what it currently has now.

Also KDE is actually looking to be the most difficult to work with of the 3 at the moment. I am delaying releasing what I am working on in my dev branch right now because of KDE. Gnome, to my surprise, has been the easiest one to work with by far, xfce 2nd and KDE has turned out to be the most difficult. KDE is having issues allowing me to properly remap the app switching I want/need. I really do not want to release new features piece meal on the bases of the DE - if it doesn't work across those 3 major DE's then I'd prefer to delay it until I figure it out.

[probonopd]

Yes, I can feel with you, I also avoid mailing lists wherever possible. I find projects on GitHub and GitLab the easiest to work with. No "issues" tab on GitHub or GitLab is always a red flag for me.

That being said, I've had positive experiences with

• https://phabricator.kde.org/ (need to make an account on https://identity.kde.org/ though, would be so much nicer if they accepted logging in through GitHub or GitLab accounts)
• https://gitlab.gnome.org/GNOME
• https://bugzilla.xfce.org/