Today I’m going to announce things. One thing has a screenshot, one thing does not. The thing without the screenshot is the important bit and the thing with the screenshot is simply to get peoples attention. I know how this marketing thing works.
I’ve been working on Gypsy for a while now and it is a GPS daemon. It uses Glib and D-Bus and handles Bluetooth and serial port GPS devices natively (ie you don’t have to use rfcomm to create a /dev entry for a bluetooth device before you run it). It has a website – http://folks.o-hand.com/iain/gypsy
The reasons I wrote it were because I was increasingly annoyed by gpsd’s shortcomings in many areas and I think I fixed them with Gypsy. A quick overview on how it works:
The gypsy-daemon process is started (currently at system boot, D-Bus 1.2 should solve that hopefully) and waits, doing nothing. Clients use D-Bus to tell gypsy-daemon to connect to a GPS device, and gypsy-daemon parses the NMEA sentences firing D-Bus signals as things change. The clients set up listeners for what ever signals they want and they *only* get woken up when that signal is fired. This means that clients which don’t care at all about the satellites changing do not have to listen for the satellite signal and they won’t get woken up every time the satellite changes (which is generally once every second). This technique allows Gypsy clients to use the minimum of power. Which is good for handheld devices…
Gypsy also comes with LibGypsy which is a nice wrapper library that contains GObjects that make using the D-Bus API really simple. There is also full API documentation and a tutorial.
Obviously at the moment Gypsy only supports basic NMEA commands, but is perfectly usable to get GPS data. There may be bugs here and there, and as there are a myriad myriad different GPS devices out there it’d be nice if people could test it and see if it works with them. If it doesn’t, it would be nice if you could put the NMEA log of the device in question on the bugtracker . The log can be got with the –nmea-log command line option when running gypsy-daemon. Thanks…
So, that was the bit I’m most excited about – Gypsy, but I know that people like screenshots and screenshots of GPS output on a terminal isn’t the most exciting thing to look at. Trust me, I know… To that end, and so that if any fools gets excited enough about the next part to pass the word around then my Gypsy stuff will get pulled along with it….Haahaa! A cunning plan I think you’ll agree…
Anyway, I’ve also been playing about with putting a compositing manager inside Metacity. I know this has been attempted before but the aim then was to put an all singing, all dancing, superduper effects overdrive 3D GL based compositor inside it. And it failed. But I don’t think this is the right approach anyway and most people I’ve spoken to and respect don’t want silly 3D spinning cubes or desktops that you can look down the side of your windows or fish, they just want translucent windows and drop shadows. I’ve been working on shoehorning xcompmgr into metacity. I figure that with enough force you can make anything stick together. And it seems to work.Well, for various defintions of works. There’s rendering glitches and silly things have shadows while sensible things that should have shadows dont, but its working well enough for me on both my desktops to use full time. Trying to get the core stable enough before adding all the finishing bits.
The code is in the subtly named iains-blingtastic-bucket-o-bling branch of metacity. The code is ugly, evil and a nasty hack at the moment (unlike Gypsy which is lovely code. You can test it if you want, but it will contain bugs, it will eat your data, it will shoot your cat, crash your car, drink all your beer and force your children to make clothes for GAP. (Gypsy on the other hand will not do any of that stuff at all…use it, it’s lovely)