I've committed the new manual position backend. Adding the possibility to modify coordinate data, civic data or both in gconf made it a bit more complicated, but seems to be working now (signals and all).
The coordinate-->civic geocoding does not work but that seems to be a geocode_yahoo-backend problem. The other way round it's pretty nice: Setting any amount of civic location data in gconf (say, just the City and Country) emits both a civic_location_changed and, after geocoding, a current_position_changed signal. There's a "valid_until" gconf-key that needs to be set to a value higher than current time, or the backend won't emit the signals. I'm still open to other, more generic solutions. Todo list: * Implement service_changed signal emission * Add gconf schemas * refactor (it's fairly rough right now, but I wanted it in so Keith won't break my tree with more API changes :) Some observations about API changes: * civic location method/signal should have timestamp argument too? * I assume timestamp is time of original data retrieval, in case of manual backend that would be when user inputs the data? * Maybe current_position should actually work like "last_position": always return the last valid position and let the client check if timestamp is acceptable? If clients are interested in current data, they should subscribe to signals anyway... The function should be renamed though: "current" just doesn't describe this behaviour.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ GeoClue mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/geoclue
