mtppics: a script for copying pictures off of Android phones

Way back in the old days, Android phones could be mounted like any other FAT-32 device (think thumb drives) on a Linux computer. Life was good. Somewhere along the line, Google changed this so the phones are instead exposed at Media Transport Protocol (MTP) devices. In some ways, this is an improvement. For one, the “USB mass storage” option required exclusive access; you could access files on your phone from your computer or from your phone, but not both.

However, using KDE’s Dolphin file browser was often an exercise in futility. File transfers would almost always fail, and maybe if you disconnected and reconnected the phone, it would work better. Or maybe it wouldn’t. As it turns out, this appears to mostly be a Samsung problem and is WONTFIX’ed by KDE developers.

I initially worked around this problem by writing a quick script that mounted the phone to a known location using simple-mtpfs, a FUSE driver for MTP. This allowed the contents of the phone to appear as a normal filesystem; my wife and I could copy pictures off with Dolphin or any other tool we wanted.

This worked pretty well, until it didn’t. I’m not sure why, or when exactly, but at some point it had stopped working. It mounted okay, but using Dolphin to access the files still crashed the MTP stack. I normally use the terminal to do the file copy anyway, so it didn’t bother me, but my wife is much more GUI-oriented.

So a few nights ago, I sat down to come up with another option. The real goal was just to be able to copy pictures from the phone to our file server, not to browse around arbitrarily. This meant that I could go for an automated solution. Initially, I thought it would be best to use MTP directly, but that turned out not to be a good idea. The PyMTP library provides a good interface to MTP, but it turns out the files are exposed as a single set of objects, not a hierarchy.

So I could have continued with that route, but it would have resulted in me basically writing my own FUSE driver, so I decided that was not how I wanted to spend the rest of the evening (and many of the next evenings). In the interests of having something usable, I continued to use simple-mtpfs, but I put all of the heavy lifting into the script.

The result is mtppics, which will copy pictures from a directory on the phone to a local directory. With a little bit of trickery and the date command, you can handle a variety of date-based target directories. It’s still very much designed for how my wife and I have our pictures archived, but I’m open to making it more flexible. I’ve tried to make it fairly robust to failure (I even used a trap statement!), but there are probably opportunities for improvement there, too. Give it a try if it would be of use to you and let me know how to improve it (or submit a patch, if you’re into that sort of thing).

What I want in an Android keyboard

Despite the fact that approximately eleventy billion keyboard applications exist in Google Play, I’ve always been fairly content with the default keyboard that Samsung puts on the Galaxy S4. I write tweets — and occasionally blog posts — on my phone, but otherwise I don’t do much in the way of content creation. I certainly avoid doing anything intense if it can at all be avoided. I have SSHed into servers to bounce daemons or otherwise fix glitches before, but I certainly don’t like to.

Last weekend, T-Mobile pushed an update from Samsung that slightly changed the keyboard layout. The comma key that used to be on the bottom was no longer there. Now I can’t say with 100% certainty that there used to be a comma key, but muscle memory is a powerful thing and in the past week, every time I tried to type a comma, I hit the voice typing button instead. I can’t find any way to restore the old layout (thanks, Samsung!), so I’m forced to either adjust to it or find a keyboard that I like better.

I’ve never really given on-screen keyboards much thought. In the past, week, though I’ve started actively thinking about what I want from a phone keyboard:

  • Easy access to punctuation. I tend to observe grammar and punctuation rules in tweets when practical, and I’ve learned that a use commas a lot. The less effort it takes to use common punctuation, the better.
  • Easy access to hashtags. Since most of my writing is in tweet form, you’d expect that I would type a lot of octothorpes. You’d be right.
  • Easy access to emoji. Yes, I like to use emoji. I don’t have to explain myself to you.
  • Stay out of my way. It might be more efficient to take advantage of certain ways keyboards try to be helpful (for example, inserting a period when the space bar is pressed twice), but mostly I don’t do that. Auto-whatever tends to lead to more errors than just letting me do it myself.

That’s basically it. I’m not a complicated person. So over the last few days, I’ve tried out a few different keyboards to see which one I like the best.

The competition

Google Keyboard

Google Keyboard

Google Keyboard

This is the default keyboard on stock Android. I’ve used it some on my crappy, no-name tablet and haven’t minded it (the terribleness of the hardware makes it hard to have much of an opinion on the keyboard). The comma key is a big bonus, and the voice typing key is in the predictive text row (not pictured), which helps keep it out of the way.

The numbers not being their own keys is a little bit of a hassle, but for the most part it doesn’t really matter. Unobviously, the emoji are available by a long press of the enter key. The emoji keyboard scrolls horizontally instead of vertically, but that’s no bother. My main disappointment is the need to use a secondary keyboard to get special characters instead of a long press.

Samsung keyboard

Samsung keyboard

Samsung keyboard

I had to give the incumbent a chance. It mostly covers all of my requirements, but the lack of a comma key really cramps my style. It’s available as an alternate on the period key, so I could probably get used to it with time. I particularly like having many special characters available via long press.

SwiftKey

SwiftKey

SwiftKey

SwiftKey has a layout pretty similar to Samsung Keyboard (too similar, sometimes, as the special keys aren’t all in the same place). It’s very configurable; the ability to specify the length of a long press is particularly excellent. Emoji and special characters are easy to get to, the never-used voice button is hidden behind a long press, and it has an alternate mode for numeric typing.

Swype

Swype

Swype

Swype came pre-installed on the phone. It has a neat feature in that you can shrink it and put it on the left or right side, which is probably handy for people with short thumbs (or bigger phones). The keyboard can also be split so that there’s a gap in the middle to help with two-thumbed typing on larger devices. It has an emoticon secondary menu, but I couldn’t seem to find a way to get emoji. That’s a big strike for me, though people who don’t use emoji will probably find this to be a suitable keyboard.

The Verdict

For now, SwiftKey looks like the winner. Google Keyboard is a close second, but the lack of long-press-for-special-characters hurts it. SwiftKey seems to have everything I want out of a keyboard. It still feels a little weird, but once my muscle memory adjusts to the slightly different layout, I think I’ll be in good shape. If you have a favorite keyboard, I’d love to hear about it in the comments.