Posts Tagged ‘keyboards’

Introducing Quimby: Context sensitive keyboard chording in a GTK input method

June 21st, 2015

A number of years ago, I found myself wanting to be able to use a greater variety of compose sequences than were generally available for Linux users. Compose sequences are great, and let you enter lots of different accented characters that occur in various languages that use the Latin alphabet. For example, you could type [compose] + e + ‘ to get “é”, and [compose] + c + , to get “ç”. But if you wanted to type “ǫ” you were out of luck. (It’s used in Old Icelandic, and I actually did want to type it once, to input a song title.)

The way to I found to fix this problem was to write a GTK input method module. This is the chunk of code that takes input from the keyboard handler system (xkb) and performs alchemy upon it to produce the characters that show up on the screen when you enter some text in a box. Not every Linux application would use my module. GTK is just one of a number of GUI toolkits used by Linux applications, but it’s a very common one, and it’s the one used by all of the applications I use frequently.

Over time the stock GTK input method has improved somewhat in the range of compose sequences it supports, but since I had input method code of my own, from time to time I found features to add to it. For example, it annoyed me that there was no keyboard shortcut for directly pasting selected text, so I made [compose] + [insert] do just that. (In Linux you can paste selected text (without explicitly copying it) with a middle mouse button click, but in GTK apps you can’t normally do that with the keyboard.)

More recently, I was trying to think of a way to do something about the problem of the inefficiency of typing English. One spends quite a bit of time typing common words. For example, whenever you type “the”, it takes four keystrokes, counting the space after the word. Stenography allows users to reach much faster speeds of text input by pressing multiple buttons at the same time. Most common words can be input using a single chord of button presses.

People who have mastered stenography are typically able to input text at three times their typing speed. The downside is that stenography has an extremely steep learning curve. One can spend months or years in intensive study to reach that plateau, and it can take quite a while just to break even. It’s also a system that has been designed for natural language text input, but computer keyboards have been designed to perform other sorts of tasks as well, like performing commands in applications, and writing code, where punctuation is used in a very different way from how it is used in natural language. (I should note that some efforts have been made to remedy this situation in Plover, an open source stenography implementation.)

Intrigued as I was by the possibilities of stenography, I felt rather daunted by the learning curve, and the expense and/or trouble required to buy or make the specialized hardware required. But what if there were some way to use chorded strokes on a regular keyboard to represent the most common words? Then we could have a system where the learning curve could be relatively modest, as normal typing would always be available. The ceiling of the speed increase would be modest as well, but it looked like an increase of about 10% to 15% might be possible. That’s not nothing. And my GTK input method was just the place to put the code that was needed to make it happen.

The space bar, being the easiest key on the keyboard to hit, was very tempting to use to signify that we are typing a chord that we want expanded. For example, we could use [space] + t to expand to “the “, saving two keystrokes. Since those keystrokes occur simultaneously, it’s almost as good as saving a third. Conveniently, we normally type [space] once per word anyway, so this should feel fairly natural. But simply expanding chorded keystrokes wouldn’t work. The problem is that in normal typing, it will frequently happen that the key press event for one key will occur before the key release event for the previously pressed key. You could be typing “hat rack”, and get “hathe rack” if you typed too quickly.

Fortunately, there was a simple solution. The key insight was that the only time you want a chord to expand into a whole word is when you are at the start of typing a word. And you can detect that, through the context that the input method supplies: GTK input methods allow you to access the text around the cursor. If the cursor is after a space, you are at the beginning of a word. (It’s more complicated than that; you can also be at the start of a word after certain punctuation, and sometimes you are at the start of a sentence, and we should detect that, and automatically capitalize the word we are expanding. But that was enough to get me started.) The problem of mistaken expansions wasn’t entirely banished. You could type “a tree”, and accidentally chord a + [space] + t, which expands to “at “. That’s unfortunate, but if you train yourself to always type the word “a” with an “a” + [space] chord, you can avoid the problem.

The choice of chords to represent common words is an intriguing puzzle in itself, and a matter for a future post. If you run GTK apps, (which means you are probably running Linux) and are interested in trying out Quimby, (short for “Questionably Useful Input Method? But Yes.”) the code is available on GitHub. I make no guarantees about its stability. It’s quite possible that it will crash and make you lose data! But the current iteration has been stable for me of late, and I used it to write this very post. The available chords aren’t documented yet and are still very much in flux; to see what they are currently, read the source. (src/chording.c) Eventually, I want to have the chord list be user extensible, but I’m not there yet. There is still more work to be done, adding more chords, detecting better when we are at the start of a word or a sentence, and supplying a few more features that will make using chording more convenient. But it’s ready to be shown off, and I am interested in hearing what people think about it.

How I made a laptop

May 29th, 2015

I suppose I should preface this by saying that I don’t recommend that anyone do what I did, nor do I recommend that anyone, having chosen to do what I did, should do it the way that I did it. But I learned some things in the process of doing it, and maybe somebody else will find these things interesting. What did I do? I made a laptop:


Why did I do it? Well, my last (real) laptop died last year. When I was considering a replacement, I decided that I’d probably get more use out of a tablet, since it would be portable enough that I could take it more places. I found a good deal on a refurbished Samsung Galaxy Note 8, and bought one.

But there are some circumstances where I would prefer to have a laptop, with a real keyboard. Programming and writing are a couple of my hobbies, and I’d like to be able to do them away from my desk. I found the on-screen keyboard on the tablet adequate for tasks that require a small amount of typing, like entering data on web forms, but not for more serious text entry. The germ of the idea then took root: if I had a keyboard to use with the tablet, I could connect them together in some way to make a laptop. (The process would have to be reversible; I would sometimes only want a tablet with me.)

Now, there are tablet cases with integrated keyboards that are made for just this purpose. But these keyboards typically require some compromise in typing comfort, compared to a standard keyboard. For my desktop keyboard, I use a mechanical keyboard without a tenkey, since I find that I never use it anyway, and its absence allows me to place my mouse closer to the keyboard, which is ergonomically advantageous. (If you are a particular sort of keyboard geek, you may be interested in knowing that it uses Cherry MX Brown switches.) But for the fake laptop I wanted to make, I wanted something more compact than my desktop keyboard.

There are some highly compact keyboards out there, but I did not want to lose the standard arrow key block. Keyboards that are more compact than a tenkeyless keyboard, but that retain the arrow key block, are a rarer breed. But a good deal on just such a keyboard, a Keycool 84, popped up on MassDrop, and I sprang for it. (You may notice a pattern. I am a sucker for a deal.) I might have preferred a keyboard without a function key row, but this was close enough.

Now I had the tablet and the keyboard, and was left with the task of connecting them together. I knew that I needed hinges, but I didn’t know anything about what the particular hinges I needed were called, or how to get them. I knew that they needed to stick in place when acted on by a small force, (like gravity acting on the tablet) but move when acted upon by a larger force (like me setting the angle of the tablet to the keyboard.) (The process of getting information out of search engines when you are starting from a position of complete ignorance of basic terminology is interesting in itself. My initial flailing led me to forums where artists were discussing making pochade boxes. That didn’t immediately teach me what I needed, but at least I had a relevant term to search.)

Having determined that I wanted what were called either “friction hinges” or “torque hinges”, the next problem was the matter of exactly how sticky the hinges needed to be. The stickiness of a particular hinge is rated according to the torque required to move it. This brought back memories of high school physics, but I wasn’t entirely confident that I could calculate the proper value for the torque of the hinge, given the weight and dimensions of the tablet. An online torque calculator was helpful. Both adjustable torque hinges and constant torque hinges are available; the former appealed to me because they would provide some leeway in case I wasn’t quite right about the proper stickiness for the hinge. Adjustable torque hinges are also the cheaper option, and I found a deal on ebay for a set of four Southco E6-10-301-20 hinges at a better price than I could get for one hinge of that model anywhere else.

Unfortunately, the leaves of the hinges weren’t long enough to be able to attach directly to the keyboard and the tablet. I needed a couple of extension pieces. I settled on lasercut plastic for these. (I ordered the laser cutting though Ponoko, as usual.) In the past, I’ve mostly used acrylic for my lasercut puzzles, but for this project I used delrin. Acrylic can break under compression; it seems that delrin is better when you are using screws and nuts to fasten things.

Which I was. The screws and nuts were actually the last pieces I acquired. As with hinges, this was an area where a dizzying array of options are available, and I lacked the vocabulary going in to specify what I wanted. On top of that, I wanted a much smaller quantity than is typically purchasable, either online or at large chain hardware stores. Fortunately, a friend of mine recommended Parkrose Hardware in Portland, which sells individual screws of a large variety of types. Being able to pick them out by hand and see which ones fit properly into the hinges helped me make the right choice. (In this case, #8-32 3/8″ pan head machine screws.)

At this point what remains to be discussed is how I attached the delrin pieces to the keyboard and the tablet. As I said before, the tablet had to be able to be attached and unattached. I decided to use Velcro for that. I placed four adhesive-backed Velcro squares (loop side) on the tablet, and the matching hook squares on the delrin piece. On the keyboard side, I didn’t care if the delrin piece was attached permanently, and I wanted something that would make a stronger connection than Velcro, so I used a piece of 3M automotive super strength molding tape, which I had lying around. I got the placement of the delrin piece very slightly off, but I was stuck with it, as the super strength tape was indeed as advertised.

And that’s it. Of course, none of this would be at all useful if I couldn’t connect the keyboard to the tablet. I used a USB On The Go adapter for that, which works fine, although I might at some point see if I can find a shorter keyboard USB cable, since the one that came with the keyboard is quite a bit too long for this purpose. The one other thing I am a little unhappy with is that the hinges won’t close as far as I would like. Slightly thinner delrin might have fixed this problem, but if it were too much thinner, it wouldn’t hold up the tablet without bending.