|
|
| Line 1: |
Line 1: |
| == GeoClue and KDE 4.3 ==
| | {{ Moved To Community }} |
| | |
| === Status of location awareness in KDE trunk ===
| |
| | |
| There are at least two programs in KDE that want to integrate location awareness: Plasma (as a data engine), and Marble. Marble has code for interacting with HostIP and a (non-working) integration of libgps. Plasma has a data engine that interacts with libgps and HostIP.
| |
| | |
| | |
| === Benifits of using GeoClue in KDE ===
| |
| | |
| GeoClue provides location awareness in a simple DBus API. Interaction with HostIP and gpsd is already possible.
| |
| | |
| In addition, GeoClue also provides other means of retrieving geolocation data, e.g. by using GSM cell positions on suitable devices.
| |
| GeoClue also allows extension via new providers which only have to depend on DBus.
| |
| | |
| Furthermore, GeoClue shares location data between different applications, so that only one HostIP request is needed for several applications using GeoClue framework.
| |
| | |
| | |
| === Drawbacks of using GeoClue in KDE ===
| |
| | |
| ==== Problems with the DBus API ====
| |
| | |
| One major problem with the API is that it is totally undocumented. Semantics of different functions are not clear at all.
| |
| | |
| It is believed that the SetOptions function in the org.freedesktop.Geoclue interface does not serve any use. Since providers can be shared by different applications, setting options in one application can have side-effects in another application.
| |
| | |
| ==== Problems with the current implementation ====
| |
| | |
| The current implementation depends on GConf, which is a no-go for an application used by KDE. It is questionnable whether configuration is needed at all - see also section above.
| |
| | |
| There is a crash in the master provider when used in combination with the gpsd provider, which makes the master provider and therefore GeoClue currently unusable for KDE.
| |
| | |
| The project does not seem to be very active at the moment. Response times are quite high.
| |
| | |
| | |
| === Possible further actions ===
| |
| | |
| ==== Polish the current implementation and reconsider GeoClue at a later release ====
| |
| | |
| Advantage: working geolocation is available in 4.3.
| |
| | |
| Disadvantage: every KDE application brings its own implementation.
| |
| | |
| ==== Urge the maintainers of GeoClue to fix the bugs in time for 4.3 ====
| |
| | |
| Advantage: one common desktop API for geolocation.
| |
| | |
| Disadvantage: dependency on external project for our feature plan.
| |
| | |
| ==== Fix the bugs in GeoClue ourselves in time for 4.3 ====
| |
| | |
| Advantage: at least the implementation gets fixed before 4.3.
| |
| | |
| Disadvantage: we have to take care of C code, we still have to get in touch with current maintainers to apply patches and discuss DBus API.
| |
| | |
| ==== Write a replacement for the GeoClue implementation in time for 4.3 ====
| |
| | |
| Advantage: working geolocation is available in 4.3; we have some nice C++ program.
| |
| | |
| Disadvantage: sounds a bit like NIH, more work than the other solutions.
| |
| | |
| | |
| == Resources ==
| |
| * http://geoclue.freedesktop.org/
| |
