At this year's edition of Camp KDE, John
Layt reported in on his research to try to determine the right
course for adding geolocation features to KDE. Currently, there is no
common API for applications to use for tagging objects with their location
or to request geolocation data from the system. There are a number of
different approaches that existing applications have taken, but a shared
infrastructure that allows geolocation data to be gathered and shared
between applications and the desktop environment is clearly desirable.
Layt began by explaining that he had more than a passing interest in
geolocation, partly because he was born in New Zealand, has lived in
Australia and South Africa, and now lives in the UK. Along the way, he has
visited 47 countries. He has been studying archeology and how to use
Geographical Information Systems (GIS) for that work, which have a clear
connection to geolocation. He is best known in
the KDE community for his work on calendars, holidays, and printing
("don't ask" about how he got involved in the latter, he said).
In 2002, he started writing a virtual globe application called
Kartographer, which is a distant ancestor of today's KDE globe application,
At the base level, geolocation consists of using and recording geographic
correspond to a particular location: latitude, longitude, and altitude will
locate a point in 3D space. But there are additional pieces of information
that are generally useful, like heading and velocity for navigation
applications, as well as the accuracy of the coordinate information. GPS
provides data accurate to within 10m or better, while IP address
information provides far less accuracy (typically just narrowed down to a city
at best). Generally applications are interested in two levels of accuracy,
that more or less correspond to those measures, which he termed "fine" and
There are additional services that should be provided by a geolocation API,
such as the current location of the device, as well as historic position
information (i.e. where was the object 1 minute or hour ago). Converting
things like addresses to geographic coordinates (geocoding), and the
reverse, is also
required. There are multiple possible providers of location information,
GPS, IP address, cellular network location, visible WiFi access points, and
so on, and there needs to be ways to switch between them. An application
should be able to specify that it only needs coarse location information
and the geolocation subsystem should use the appropriate provider(s).
Geolocation information is used in mapping and navigation applications,
but there is more than just map data involved as there are various points
of interest that get incorporated: landmarks, places, businesses, and so
forth. Obviously, these kinds of applications are huge on mobile devices,
but there is no good reason that desktops should not have access to the
same kinds of data. Providing a geolocation framework just for mobile
devices is an "arbitrary split", and one that shouldn't exist,
Layt said. "Why should mobiles have all the fun?"
Geolocation can be added to applications beyond the obvious
mapping/navigation programs, and Layt mentioned several, including star map
applications like KStars (using the Android Sky Map application as an
example), weather plasmoids (noting that his laptop was still showing London
weather after he arrived in San Francisco), proximity for social
and messaging applications, and mapping locations in address books.
He said that there are "many many
more" applications that could use geolocation if it were more easily
He also noted some specific applications that already use
geolocation. digiKam can place photos on maps based on coordinates in the
metadata or add those coordinates to photos that lack them. It allows for
fairly sophisticated searches ("give me all the photos within 100m of a
particular point"), by using its own library (libkmap) which is an
abstraction over Google maps or Marble.
Layt has some ideas on other possibilities that geolocation could
enable. Changing locations could modify the state of the desktop and
system, by asking the user if they want to switch timezones or locale when
their location changes. Moving from work to home could change Plasma
activities, closing down work applications and documents, and opening up
those that make sense for home. Those kinds of decisions will require a
way to name locations (e.g. "home") and to also allow for some fuzziness in
what defines the locations. Obviously, "home" is not defined by a single
set of coordinates, and different locations will have different sizes, so
there will need to be ways to define and store that information.
HTML 5 has geolocation support that could optionally be used to send location
information to web sites for narrowing searches or discovering information
based on one's current location. In addition, the semantic desktop
(e.g. Nepomuk) could log location-based information if it were easily
The ideal solution would have single API for all platforms, mobile or
desktop. It would be lightweight so that there would be fewer barriers to
including it into those platforms. It also would be available at a low
level in the stack, so that it can be used by as much of the rest of the stack
as possible. The solution would also use free data providers for map data
to avoid the
restrictions placed by the proprietary data providers (e.g. Google or Bing maps).
A solution along those lines would allow the applications to largely free
themselves from each having to implement its own solution.
There are a number of current solutions that might be adapted for the needs
of a KDE platform solution. One is the Plasma DataEngine for geolocation
that has been used by Plasma applets, mostly for weather applications so
far. It has backends for gpsd or IP-based geolocation but does not provide
support for geocoding.
Marble and libmarble have an extensive feature set for geolocation and
mapping using free data providers. The library has few dependencies and can
be used in a Qt-only mode, so that there are no KDE dependencies. The
library itself is around 840K in size, but the data requirements are,
unsurprisingly, much higher, around 10M. The biggest problem with using
libmarble is that it does not provide a stable interface, as binary and API
compatibility are not guaranteed between releases.
Another option is GeoClue, which is a freedesktop.org project for
"geoinformation" that has support for geolocation, but not mapping. It is
lightweight at 370K and includes multiple backends, choosing which to use
based on the accuracy requirements of the query. One big problem, from the
perspective of the KDE project at least, is that GeoClue has a dependency
on gconf to provide a single configuration setting. Layt said that the
GeoClue developers have been reaching out to KDE to suggest that it use the
service, but the gconf dependency makes that impossible. Layt and others
have been trying to get that changed for some time, but it hasn't happened
yet; the projects need to work together to get that solved, he said.
The QtLocation module, which is part of the QtMobility framework, has
support for geolocation, mapping, and landmarks. It only does simple tile
maps and its landmarks are stored in non-standard ways, but those can be
translated into a usable format. It lives low enough in the stack for use
by the rest of the system and is supported and available for all mobile
platforms. The desktop version is not maintained, so work would have to be
done there, though there is a version for MeeGo that could be adapted for
Linux desktop use. The biggest problem with QtLocation is that the
available backend is for Ovi Maps, which comes with a huge number of
Layt said that the Ovi Maps restrictions were much like those placed on the
data from other providers like Google and Bing. The data providers
"don't want you to do anything terribly useful with the
data". There is a laundry list of things that are forbidden with
Ovi Maps, such as reusing the data in a way that competes with the Ovi Maps
application or altering the data that gets returned from the server. It
requires registration to use, may not be available in some countries, and,
rather oddly, requires "good manners" from its licensees.
There were indications that Ovi Maps might be opening up to more uses not
so long ago, but Layt didn't seem very optimistic about that given the
recent events at Nokia. Basically, he said, KDE needs to use free data
from sources like OpenStreetMap.
In summary, there is no current solution that meets the needs of KDE. For
now, mobile applications should probably use QtLocation, desktop
applications should use libmarble, and Plasma applets should use the
DataEngine. For the future there are several possibilities. Layt would like
to use libmarble, but the lack of a stable API/ABI makes that difficult.
QtLocation is stable enough but would require backends for free data
sources. GeoClue is also attractive if the gconf dependency can be removed.
He would like to see if a decision on the right approach could be made at
the Platform 11 Sprint
that will be held in June.
Camp KDE is the yearly gathering of KDE developers in North America, and is
meant to help reconnect developers in that region with their more numerous
European counterparts. This is the third Camp KDE and the fourth KDE event
held in North America. Around 35 people attended the first day's sessions,
with many of those attending Camp KDE for the first time. Celeste Lyn Paul, who
helped organize the event, noted that attracting "first timers" was exactly
why the event exists, to try to grow the North American community both in
size and in the minds the KDE communities elsewhere in the world.
Comments (9 posted)
Version 0.2.5 of the Coccinelle semantic patch tool has been released. New
features include support for iterating a patch over a code base and,
primarily, beginning support for the C++ language.
Full Story (comments: none)
The GNOME 3.0
press release has gone
out. "Today, the GNOME Desktop project released
GNOME 3.0, its most significant redesign of the computer experience in
nine years. A revolutionary new user interface and new features for
developers make this a historic moment for the free and open source
" More information and downloads can be had at gnome3.org
Update: the real release
announcement is now available.
Full Story (comments: 87)
The GNOME 3 release has not been announced as of this writing, but a
special edition of the GNOME Journal is available in the meantime. There
are articles on the history of this release, GNOME 3 fonts, developer
interviews, and more; it's all at gnomejournal.org
Full Story (comments: none)
Greg Ward has announced the "All Mercurial Extensions" project, which is: "a meta-repository that gathers together all known
Mercurial extensions that are not included with the latest version of
Mercurial, as listed in the Mercurial wiki.
" It's meant to make it
easier to find extensions, see how they are affected by core Mercurial
changes, and serve as a working example of a repository with subrepos.
Full Story (comments: none)
Newsletters and articles
Comments (none posted)
The H describes
Mozilla's plans to remove the ability to embed the Gecko layout engine into other programs. This will affect projects like the Galeon browser
and other programs that currently embed Gecko. "In a posting to mozilla.dev.embedding, Embedding Module owner Benjamin Smedberg said that Mozilla had been considering the future for embedding Gecko in other applications. He cites the difficulty involved to date, the expected complexity of moving to a multiple process model and the desire to "strongly prioritize" Firefox as the key product of Mozilla. There is a possibility that embedding support could return in the future after Mozilla has moved Firefox to a multi-process model, but the developers are not going to [prioritize] that as a goal in their design work.
Comments (52 posted)
Andrew Brown has posted the
first part of a tutorial
on how to use PyPy to create an interpreter for
a new language. "Wouldn't it be nice if you could write your
language in an existing high level language like, for example, Python? That
sure would be ideal, you'd get all the advantages of a high level language
like automatic memory management and rich data types at your disposal. Oh,
but an interpreted language interpreting another language would be slow,
right? That's twice as much interpreting going on. As you may have
guessed, PyPy solves this problem.
Comments (7 posted)
Page editor: Jonathan Corbet
Next page: Announcements>>