At Akademy earlier this year I presented the current state of KPublicTransport, and mentioned a remaining privacy-relevant issue in there for giving its users full control about which backend service to query. This has now been addressed, with a way to list and chose backends globally or per request.


KPublicTransport needs to retrieve its information online, and for that is supports a number of different backend services. So far those have been selected as follows:

  • For any request that contained geographic coordinates, only backends who’s geographic bounding area includes any of the coordinates is considered. Even in densely covered areas that’s not more than three or four candidates.
  • For requests only containing location names all backends were considered. As we are approaching 30 backends that’s getting too much, even when leaving privacy concerns aside.

In a best-case scenario we would be able to pick one appropriate backend automatically, and on top of that allow users to exclude certain backends explicitly, e.g. because they don’t trust the operator, or the privacy laws applying to the operator. The latter is straightforward, the former not so much. Making good choices for appropriate backends requires context information beyond what the KPublicTransport framework has access to, so to some extend we need to offload this to the application. Therefore we need API giving applications full control over backend selection.


The newly added API can be found in the following places:

  • KPublicTransport::Manager::backends() provides a list of all available backends, to give applications the necessary information to show a selection UI to the user, or to make choices itself.

  • KPublicTransport::Manager::set[Enabled|Disabled]Backends() allows you to set the globally selected backends. The reason this tracks both enabled and disabled backends explicitly is to provide a third state (“default”), for newly added backends that haven’t been explicitly enabled or disabled yet. These methods work just on backend identifiers, so you can directly use them with QSettings or KConfig.

  • KPublicTransport::BackendModel provides a convenience model to offer a backend selection UI to the user, usable from C++ or QML.

KDE Itinerary showing a configuration page to select which public transport services to use.
Manual public transport information service selection in KDE Itinerary.
  • KPuclicTransport::xxxRequest::setBackends() allows to override the global backend selection per query.

Backend Metadata

For selecting backends applications might need additional information about a backend. Right now we only have a human readable description and the geographic bounding area, but we can easily extend that as needed.

Backend meta data is stored in simple JSON files, together with the parameters needed to contact the corresponding service. ISO 3166-1 country codes and ISO 3166-2 region codes would seem like a useful addition, but I’d like to wait for actual application developer feedback first before extending this (hello KTrip :) ).