< Marble Revision as of 14:35, 6 April 2009 (view source)Eckhart (talk | contribs)← Older edit Revision as of 21:01, 10 March 2016 (view source) Ochurlaud (talk | contribs) m (Ochurlaud moved page Projects/Marble/GeoClue to Marble/GeoClue)Newer edit → (No difference) Revision as of 21:01, 10 March 2016 Contents 1 GeoClue and KDE 4.3 1.1 Status of location awareness in KDE trunk 1.2 Benifits of using GeoClue in KDE 1.3 Drawbacks of using GeoClue in KDE 1.3.1 Problems with the DBus API 1.3.2 Problems with the current implementation 1.4 Possible further actions 1.4.1 Polish the current implementation and reconsider GeoClue at a later release 1.4.2 Urge the maintainers of GeoClue to fix the bugs in time for 4.3 1.4.3 Fix the bugs in GeoClue ourselves in time for 4.3 1.4.4 Write a replacement for the GeoClue implementation in time for 4.3 2 Resources GeoClue and KDE 4.3 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/ Retrieved from "https://techbase.kde.org/index.php?title=Marble/GeoClue&oldid=87165" Content is available under Creative Commons License SA 4.0 unless otherwise noted.