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 only have one device to test with