Journey to Kinto

I have made an earlier post that described some of what went into the creation of Kinto, but I would like to give more of a back story to it, as well as some thoughts on how it has come about. You can read the earlier story here however.

So for me my foray into macOS land I guess started in grade school, without me even realizing it. My first experience on a computer was likely mac OS 7.x. And the concept of macs vs windows was not a thing in my mind. My family computer, some years later, had Windows 3.1 and DOS on it and I pretty much used Windows ever since — to the point of looking at macs with either mild discomfort or disgust on how they’re messing with my feng shui by screwing around with my control key.

Then Apple did the unexpected in my high school years and released OSX for x86, or rather a beta had leaked, and I decided that since they changed architectures that now I can finally try it and not be bothered by the expensive hardware costs — hello hackintosh. I had already been spinning up PowerPC virtual machines at the time.

I spent some years in the OSX x86 community and not long after bought my first macbook off ebay as I grew to like the OS. Some years later, 5–7 years, I realized that I spent most of my time in macOS, but that switching between it, Linux and Windows was killing my memory muscle and productivity while coding because I would get tripped up at times from superficial differences. I needed to fix it.

All I knew for sure was that I needed to commit to one design language, not 2 or 3, if I were to excel and forget about the least important thing to me — the operating system. It is mostly irrelevant to the cross platform solutions I want and need to build.

This decision has driven co-workers and friends to think I am a little crazy and even annoyance any time pair programming scenarios come into play with a non-mac user, but I digress, there’s a reason for the madness.

Ergonomics. The one key deciding factor in why I picked the more difficult path. I like how it feels to have my primary modifier key beneath my thumb and being able to keep all of my fingers on the home row.

Apple also makes it easy to use the Windows or Linux style keys, but Linux and Windows do not — for all the crying that ironically happens from some ardent Windows or Linux users. Many are also agnostic about either choice though.

Was it the better path, the better choice to make? I have no idea — I could have just as easily decided that the Windows and Linux keymap style is my path forward, but I didn’t — I picked what felt right for me. I think that is all anyone can ask of anyone about many, if not most, things in life.

You need to make a choice on what will make you feel better, happier and the idea of ever making the perfect or the “right” choice needs to go away more or less — it breeds contempt, bitterness, and dissatisfaction.

Methodologies of Kinto

Why was Kinto built the way that it was though? Why not build out keymaps like everyone else?

When I think about the project in terms of a design language it gives a very different perspective of the problem and the solution is. What are developers developing and doing when they create an app for Linux or any platform? They are following patterns set forth by the OS and the community as a whole, they aren’t picking and choosing UI and keyboard interactions purely based off of what feels right to them — but rather what users expect.

The problem is not that the Control, Super or Alt keys are in the wrong location — the problem is not with the users, or the developers. They are both fulfilling the expectations set forth by the OS creators and those before them, so to tackle it any other way is a huge waste of time and mental resources.

You will die the death of a thousand paper cuts if you tackle it one app at a time, but you will also die if you just do a simple key swap and not pay attention to key behaviors that create a seamless user experience for those that use a terminal app or apps that conflict with wordwise shortcuts.

So really what is the goal here?

“Regardless of the app, make sure the primary modifier key is always next to the space bar in a manner that is intuitive to the user and make sure the Ctrl key still operates for the expected terminal functions. Users should not need to create additional keymaps.”

How to accomplish this?

1. Know what app the user is currently using.
2. Perform the proper keymap and make use of remapping in groups to avoid loops.
3. If an app conflicts with wordwise shortcuts then detect when the input field is actively in use or not via caret activity and re-apply the proper keymap.

Whether Kinto exists as a bash, python or a c program, or a combination of the above is irrelevant as long as those 3 basic functions are performed. I have written in previous articles about some of these things and the 3rd point was the latest and I believe the last issue I had discovered that I had to resolve this project. Ultimately though this is Kinto, the solution that I came up with to a problem that seems to have gone unsolved for years.

There is no lack of brilliant people in the Linux community, far from it, but the ability of defining the full scope of the problem to reach a complete solution is often the biggest challenge any of us will ever face. And while it’d be great to be able to fully define the scope of every problem from the beginning — you still need to be flexible enough to allow your scope to either expand or contract when you can see you are losing sight of creating the solution you intend.