Marble/GeoClue: Difference between revisions
*>Eckhart New page: GeoClue support in Marble is planned, will probably replace the use of libgps. == Status of integration == * Some serious bugs in GeoClue - we need to get those fixed first * GeoClue curr... |
*>Eckhart No edit summary |
||
| Line 1: | Line 1: | ||
GeoClue | == 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 == | == Resources == | ||
* http://geoclue.freedesktop.org/ | * http://geoclue.freedesktop.org/ | ||
Revision as of 14:35, 6 April 2009
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.