Datamation content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
This year, a new dimension is appearing on the Linux desktop. It’s geolocation: the capability to detect and record where you and other people are, and to use the information to enhance the desktop. Potentially affecting everything from the metadata stored with files to the mechanics of social networking, geolocation is already starting to arrive in GNOME and KDE. But the first implementations are only a hint of the features that geolocation might soon provide.
Why add geolocation now (other, of course, than because developers can)? The main reason, according to KDE developer Aaron Seigo, is that many computers are no longer stationary. “These days, we pack around phones and PDAs, and laptops are continually slung over our shoulders. We’re an increasingly mobile society where we carry our computers with us. So computers now have a new set of requirements that just emerged in the last ten years, and they are now expected to work equally well in multiple human contexts.”
For example, Seigo says, “At work, we may not Web-surf or [use] Facebook. At home or in a train station, sure, that’s what we want to do, but probably the last thing we want to do is look over that spreadsheet from work. That’s why geolocation is increasingly important: It’s trying to make computers respond to the human context, instead of the other way around.” He suggests that, in the near future, geolocation could be used to change desktops and icons sets automatically as your location changes.
Or, to put a different perspective on the trend, geolocation is one indication of how the focus of development has started to shift from the workstation desktop to mobile devices. With Android and iPhone on one hand and Web browsers like Firefox and Google Chrome on the other hand all implementing geolocation, its arrival on the desktop is inevitable.
Work on geolocation — or, at least, discussion of the concept — dates back several years in both KDE and GNOME. According to Torsten Rahn of the Marble project, KDE has been planning the arrival of geolocation since the 2005 Akademy in Malaga, Spain. Geolocaton has been discussed in GNOME almost as long. Its first mention most likely being in Henri Bergius and Tuomas Kuosmanen’s presentation,” Feeds synchronization and the free software desktop,” which was delivered at the 2006 GUADEC in Catalonia, Spain. In the presentation, Bergius and Kuosmanen include geolocation among the changes needed in the desktop to accommodate social networking, and suggest some now-standard methods by which it might be implemented.
Since then, the two desktops have implemented different software stacks that operate in similar ways. In GNOME, the basic geoinformation service is GeoClue, with Telepathy providing the real-time messaging service and libchamplain the graphical interface for maps. By contrast, in KDE, geolocation services are an addition to the Plasma desktop technologies, and maps are rendered by Marble, which has recently evolved from an educational toy similar to Google Earth into a complete library for other applications.
These two implementations determine geolocation in several different ways. GPS is the preferred method, but weather and solar flares can interfere with its operation. Moreover, mobile devices are more likely to have it than workstations or laptops. When GPS is unavailable, geolocation can be determined by IP Address, wireless access points, cell phone stations, or manual input. Although none of these methods are as accurate as GPS, for many purposes they are good enough, and generally better than no method at all.
First implementations of geolocation
As Bergius says, implementations such as those being developed for GNOME and KDE “[make] reading and writing geographical information as simple and easy as time or date,” the two best-known pieces of file metadata in computing.
Geolocation makes its first desktop appearance in KDE in the new 4.3 release. One of the first places where users will see it is in the openDesktop.org plasmoid or applet, the first part of a plan for a complete social desktop. From this plasmoid, users will be able to see which friends from openDesktop.org are currently online and which users of the site are nearby. Another new plasmoid changes the available weather report as your location changes.
However, geolocation in KDE is likely to be most obvious in the 1.0.0 release for the image manager digiKam, which uses the new geolocation support in Plasma to allow users to tag photos with information about where they were taken. Armed with these tags, digiKam users working in KDE 4.3 are able to search and filter images, and to search and filter the images displayed based on where the pictures were taken — or, if users desire, perhaps the homes of the people depicted in the pictures.
By contrast, GNOME’s geolocation features are still in development, and are scheduled to make their first appearance in the 2.28 release. According to Pierre-Luc Beaudoin, libchamplain’s developer, these will include plugins for the image viewer Eye of GNOME, the image manager F-Spot, and the task manager Getting Things Done for adding geolocation metadata. In addition, Empathy, the instant-messaging tool, will allow users to publish their location and view that of their friends, and the Tracker search tool will have the ability to search by geolocation — something that KDE will not have until its 4.4 release.
Coming geo attractions
Both GNOME and KDE have larger plans for geolocation beyond the next releases. In GNOME, the 2.30 release — or GNOME 3.0, as it will most likely be called — is scheduled to include integration of geolocation data in both Nautilus and the new file manager Zeitgeist, as well as the panel clock, according to Beaudoin.
Similarly, in KDE 4.4, its developers plan on implementing geolocation in Nepomuk, the desktop search and analysis tool, while Rahn looks forward to a time when geolocation is part of system configuration, and its engine moves out of Plasma, so that the benefits can be enjoyed by any application built with the Qt framework, and not just KDE ones.
Further out, the uses of geolocation become more speculative, but both GNOME and KDE developers have ambitious dreams. “Imagine being able to watch your friends getting closer to a meeting point, knowing ahead who’s not going to make it on time,” Beaudoin suggests.
Even more ambitiously, Seigo notes that, KDE 4.4 is scheduled to mark the first appearance of remote widgets — small JavaScript applications that, after authentication, can be transferred between computers. For example, at a bus station, you might have the option to download a schedule to your desktop. Similarly, in an industrial setting, information from manufacturing machinery might be transferred automatically to a supervisor’s netbook as he passes by.
Seigo suggests that just as geolocation might change your desktop to match your location, it could be combined with remote widgets to automatically download already-authenticated content as soon as you move into an area. These widgets could be anything from a self-conducted walking tour around a city or a relevant Wikipedia entry to ads for invitations to play online games with people nearby. At any rate, between geolocation, remote widgets and KDE’s upcoming netbook interface, Seigo anticipates the free desktop becoming a leader in innovation.
“This is brand new stuff,” he says. “We are first out of the gate by years.” Although he is talking about remote widgets on KDE, the comment could apply equally well to all the KDE and GNOME efforts to implment geolocation. If proprietary desktops like Windows or OS X have equally ambitious plans for geolocation on the desktop, they have yet to announce them.
Growing pains
Geolocation does have problems to overcome. Although developers say that they are taking pains to make geolocation easy to use, it might prove an additional level of complexity that users see little reason to use. In particular, those who do not carry their computers around may find only limited use for it.
Another consideration is that having two separate desktop implementations — to say nothing of all the other implementations — might (with some irony) reduce the transferability of files carrying geolocation metadata. Seigo raised the possibility of KDE being able to read information from GeoClue some day, but, so far, GNOME developers do not seem to have considered compatibility with KDE’s efforts at geolocation. As for the other geolcation implementations, neither desktop appears to be giving much consideration yet to interacting with them. Still, such considerations are common with new technologies.
But perhaps the largest issues surrounding geolocation are those centering around privacy and security. The planned interactive features could easily become a new vector for viruses and malware, and even a brief description of the remote widgets that Seigo mentions can evoke fears of Big Brother-like surveillance. But these concerns are being addressed by the usual array of tools such as encryption, webs of trust and sandboxing. Moreover, as Seigo points out, having the first implementations of the technology in free software is far preferable than having them developed by a proprietary company, because any backdoors or vulnerabilities should be easier to detect in open code. Still, the concerns are likely to linger.
Whether geolocation can help users to adjust to a world of ever-changing computing contexts remains to be proved. But, for now, those experimenting with the concept are dreaming big. If they manage to implement even half of their plans, then geolocation could make the immediate future of the desktop very intriguing to watch.
