by hub, Sunday 6 November 2016 at 19:58 :: Rust :: #863 :: rss

Once upon a time, I started geotagging my photos. For that I bought a GPS logger, an Holux M-1200E. The device works great with gpsbabel, and since my photography workflow was stuck on MacOS, I used Houdah GPS (which uses gpsbabel behind the scene, BTW). Also I have been working for too long on moving that workflow to Linux and GNOME. At one point I even started to write an app I called "Magellan" to do what that MacOS tool did, as a part of my other project, Niepce. I didn't really get motivated so it went nowhere. It was written in C++ like the rest of Niepce. The technology isn't the problem here.

Fast forward, my photography machine got upgraded to a more recent version of its operating system after the one I was using was abandonned by browser vendors, and it happens that in that upgrade, the GPS logger stopped working because MacOS 10.11 stopped providing the USB->Serial driver needed. I could install some random driver, but given how much trust I have, I decided to pass. On Linux, it still works.

I had already started rewriting Magellan in Rust using gtk-rs ; I did that as just another Rust learning project. This breakage came right as a good motivator to actually push the development of that application and make it work. And it does.

The name "Magellan" was already used for some GPS related product (not surprising), so my app became GPS Ami ("Ami" means "friend" in French).

The design

I basically reimplemented Houdah GPS, UI and such. It works OK, but I think it will act as a transitionary state. I have bigger plans.

Notably, I want to allow a better control of the device, like what bt747 can do - my logger is based on that chipset, and other automation feature so I can use GPS Ami from Niepce to download the tracks. I currently only tested with the device I have.

The implementation

As explained before GPS Ami is written in Rust and uses gtk-rs for the UI. I have to be honest, gtk-rs is not ready for prime-time, but it looks very promising and I'm very happy to be able to contribute as needed. Not surprising, but you should be ready to have to put your hands in it if you want to use it. I did just that: provided more APIs, filed some bugs, sometime fixing them. I also had to implement gudev-rs to be able to have gudev functionnality for device hotplug — to plug into the mainloop. This was a learning experience.

Rust tooling is a lot about generating a monolithic binary, without data files. This is not bad per see, but when you need data files like .ui from glade to load the UI in Gtk (albeit this not required on Gtk side, it is more convenient), you are a bit stuck. Fortunately there is the includestr!() macro in Rust which mean "load this file at compile time and put it in this string".

Another problem I had was installing the rest of the files, like the .desktop or icons, problem I solved by wrapping cargo into an automake build system.

On overall, I'm just calling gpsbabel from a UI to download file.

The future

So what should come into the future?

polish the UI more, possibly tweaking it. This will probably require more gtk-rs work. IMHO there are a few show stopper for a first version.

implement a driver for this GPS, in Rust so that the actual driver be written in memory safe language.

see about adding more control feature: we should be able to read the GPS values like it is done in bt747.

support other devices officially (I don't have any other though)

Help wanted

I don't have an icon