Jump to content

Marble/GeoClue: Difference between revisions

From KDE Community Wiki
*>Eckhart
No edit summary
Ochurlaud (talk | contribs)
m 3 revisions imported
 
(One intermediate revision by the same user not shown)
(No difference)

Latest revision as of 08:05, 21 October 2016

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