New GNOME components for geolocation, predictive text, and more

GUADEC is the largest regular meeting of GNOME developers, so it always marks the roll out of a variety of new additions to the platform. At the 2013 event in Brno, Czech Republic, the new work includes a significantly revamped geolocation framework, a library-based approach to email, and predictive text input.

Geolocation

Zeeshan Ali spoke about GNOME's geo-awareness, which is undergoing a rewrite. Geo-awareness consists of four major pieces, he said. The first is geolocation, or the "where am I?" question. The second is the opposite; the user wants to find a different location: a particular address, a nearby restaurant or gas station, or other points of interest. The third issue is routing, finding the best way to get between locations. Finally, there is the user interface topic: locations, points of interest, and routes all need to be presented to the user on a map.

GNOME has had the GeoClue library for several years, Ali continued, but it has always been difficult to use. The APIs it offered were complicated to use and it exposed too many details to applications and users. For example, it provided separate APIs for acquiring location information from the different data sources (GPS, IP address mapping, etc.). Consequently, Ali and Bastien Nocera have rewritten the library as GeoClue2 with the goal of being simple.

GeoClue2 can determine location from four different sources: coordinates from GPS devices (the most accurate), the location of nearby WiFi access points (which is accurate to just a few hundred meters), the location of 3G cellular towers (which are accurate only to a few kilometers), and IP addresses (which are accurate only down to the city level).

GeoClue2 also offers better privacy controls; the previous version of the library would provide the current location to any application; with GeoClue2, GNOME will require the user to confirm location requests from each application. There are, of course, other privacy issues involved in geo-awareness. For example, Ali mentioned that Google had stirred up controversy when it mapped the SSIDs of WiFi access points. GeoClue2 will not use the Google WiFi database because doing so requires Google's permission. Instead, it plans to use an open WiFi database, but the privacy concerns are not entirely clear-cut with other services either.

GNOME's place-finding functionality is implemented in a library called geocode-glib, written by Nocera. It provides both geocoding (that is, taking a feature like a city name or street address and transforming it into latitude/longitude coordinates) and reverse-geocoding (which does the opposite, taking coordinates and identifying the closest street address). This library used Yahoo's Places API in the past, but has since been migrated to the open data service Nominatim, which is based on Open Street Map (OSM) maps, and is also more complete than Places.

GNOME already has a solid mapping UI component called libchamplain, which renders OSM maps by default. There is also a new mapping application slated for release with GNOME 3.10, called GNOME Maps.

The routing question is not solved; there is currently a Google Summer of Code student working on developing a routing system. It is a tricky problem because routing can involve several distinct modes of transportation: walking, cycling, driving, and public transport. The initial plan was to use Open Source Routing Machine (OSRM), but the public web service OSRM provides is car-only. In addition, running a separate OSRM instance (an option which would allow GNOME to find routes using OSM's bike path data, for example) is very demanding: the project recommends 128GB of RAM for the server.

Other options were discussed at a BoF session on August 7, including the GraphHopper service, which is less demanding on the server side. GraphHopper may also provide an easier solution to the public transport problem, which is tricky in its own right. The de-facto solution for publishing public transportation schedules is the Google Transit Feed Specification (GTFS), which is widely used, but there are still a variety of countries and cities that offer their own transit information APIs. Ultimately, a plugin-based approach may make the most sense (although such "plugins" would not be user-installed components).

The BoF also touched on where users would want to integrate geo-awareness in the GNOME desktop. There are certainly a lot of possibilities, from linking addresses in contact entries to the Maps application, to automatically recognizing and linking address-like text in emails or chats, to allowing the user to see the location of geotagged photos. Here again, there are privacy concerns to be worked out, as well as how best to present the potentially bewildering array of matches to a geocoding search.

Email as a desktop service

Srinivasa Ragavan spoke about his ongoing work splitting the Evolution email client up into a shared library and a separate front-end. His goal is to create a desktop "mail service" that operates over D-Bus; this would allow for multiple front-end client options as well as better integration with other GNOME desktop components.

Stand-alone email clients like Evolution are a bit of a dated concept, Ragavan said. Mobile device platforms have made users accustomed to simple "send via email" actions that can be performed from other applications, but Evolution is not capable of offering such functionality. Instead, the Evolution application must be fully started up, complete with checking for new mail from the IMAP server. In addition, the popularity of GMail as that IMAP provider behind the scenes causes other problems. GMail essentially offers one giant INBOX folder, which requires considerable time and memory to load.

Ragavan's plan is to split Evolution's account-authentication, message-retrieval, and mail-sending functionality into a separate library called Evolution Mail Factory (e-mail-factory). GNOME would store a user's IMAP credentials and start a session daemon to log in to configured email accounts automatically when the users logs into the desktop. E-mail-factory would download INBOX messages locally, using the notification system to alert the user without requiring the Evolution front-end to start up.

Splitting out e-mail-factory would have other benefits as well, he said, such as downloading messages during idle periods, and enabling search of message contents and attachments from other applications. Desktop integration would allow the lock screen to display new-email notifications (which is not currently possible), or allow the new-message-notification pop-up to include an inline reply function. It would also allow other applications to send email without starting up the Evolution GUI client. He mentioned LibreOffice and the Nautilus file manager in particular as applications whose current "send via email" functionality is painfully awkward.

Progress toward this goal is slow, but moving forward. Ragavan has split e-mail-factory out in his own Evolution builds, dating back to the 3.6 series. He is currently working on the D-Bus email API, which he described as "bare-bones" at present, and he has developed a test suite. Still to come is porting the Evolution front-end to e-mail-factory, and the final API for client applications to search and fetch messages.

Predictive text input

Anish Patil and Mike Fabian spoke about their work adding predictive input for the Intelligent Input Bus (IBus). IBus is the Input Method (IM) framework used by GNOME; it is used to speed up text entry for writing systems that do not match up with the physical keyboard. Logographic languages with more symbols than fit onto a keyboard and languages that employ frequent accents can both require considerably more keystrokes than users find convenient; Patil observed that it is not uncommon in some languages to require nine keystrokes to type five characters. Enabling the IM to accurately predict text input can cut down considerably on the keystrokes required, which in turn makes users happier.

Patil then provided a bit of background on how predictive text input works. Predictions can be based on simple statistics, or on more complex probabilistic models. The simple statistics approach would include counting the relative occurrences of letters in a particular language, or the odds that one word could follow another according to the rules of the language. More complex approaches include Markov models, where the probability of a word occurring next is determined by studying the previous history of the actual text typed. Markov models can be trained on a set of training texts, and offer probabilities based on unigrams (single words), bigrams (pairs of words), or even longer sequences.

The first implementation the two demonstrated was IBus Typing Booster, which uses a Markov model to predict words, and can be used with any IM supported by IBus. As the user types words, the booster pops up autocompletion suggestions which the user can choose from. They showed it using an onscreen software keyboard, which would be helpful for mobile and touch-screen interfaces, but of course it works with hardware keyboards as well. IBus Typing Booster is limited, however, in that it can only be used by IBus, which is far from the only IM framework available to GNOME users. It also relies on the hunspell dictionaries for its word lists, which vary in quality depending on the language.

Fabian then described the replacement tool in the works; the two are porting IBus Typing Booster over to a new library called libyokan, which will support other IM frameworks. It will handle all of the key events; applications will only have to subscribe to the prediction events and can present them to the user however they choose. Although the team is making progress, the speakers did say they are in need of help testing the new framework, improving the hunspell dictionaries, and assembling a quality corpus of free training texts.

GUADEC is always a showcase for new GNOME work and experimentation; one can never know for sure which bits will see the light of day in an upcoming stable release and which will be radically reworked while still in development. The new geo-awareness features are on track to become a major new feature, while the near-term future of the Evolution re-factoring effort and predictive text input are not as clear.

[The author wishes to thank the GNOME Foundation for assistance with travel to GUADEC 2013.]