Time for another bi-monthy status update around KDE Itinerary! Since the last report plenty of things have happened again, ranging from multi-ticket support to integration with the Plasma Browser Integration plug-in, most of which you’ll find in the upcoming 19.12 release.

New Features

The biggest new feature this time is clearly the integration into the Plasma Browser Integration plug-in for Firefox and Chromium. That has been in the works since the Nürnberg sprint, and required a number of changes throughout the infrastructure and in the browser plug-in.

Plasma Browser Integration pop-up showing details of an event mentioned on the current website.
Plasma Browser Integration offering to add an event to KDE Itinerary.

More work is still needed on this so that KDE Itinerary can also consume “timeless” elements properly, such as hotel or restaurant information without an associated booking. For that we need Kirigami date/time controls first though.

Another new feature is support for multi-ticket reservations. That’s for cases where a single traveler has multiple relevant tickets for a single journey section, such as a separate seat reservation or a first class upgrade next to a regular train ticket. Those cannot be merged, and the UI needs to be able to alternatively show both tickets. This is done by leveraging existing infrastructure for multi-traveler reservations. In the course of this, we also added support for decoding RCT2 upgrade tickets.

KDE Itinerary offering to select between the main and upgrade ticket of a train trip.
Multi-ticket selector in KDE Itinerary.

The built-in weather forecast in the KDE Itinerary app can now also indicate expected high wind speeds, thanks to the Breeze icon theme gaining support for that in its weather icon set.

KDE Itinerary timeline showing a weather forecast with windy weather.
Weather forecast in KDE Itinerary indicating windy weather.

Infrastructure Work

As usual a lot of things happened behind the scenes as well:

  • The custom extractor API as well as the generic extractors became more flexible and powerful, there’s a separate post covering most of this. Since then we also added access to UIC 918.3 vendor blocks for the custom extractor API, and content-based extractor selection.

  • KPublicTransport received API to explicitly control which backend services to query, and the UI for this has been integrated into KDE Itinerary’s settings page. There’s also a dedicated post about this.

KDE Itinerary showing a configuration page to select which public transport services to use.
Detailed public transport information service selection in KDE Itinerary.

  • The generic PDF extractor now also considers the creation and modification time in the PDF meta-data as context information, which allows us to get the date right in more cases for PDF boarding passes (which in their barcode annoyingly only contain the day, not the date).

  • The train station database of the extractor engine now also supports Indian Railways station codes, and contains all stations with such a code from Wikidata. Together with the content-based extractor selection this should pave the way for supporting Indian Railways SMS tickets.

Fixes & Improvements

Besides these larger changes, there are of course also plenty of small improvements worth noting:

  • The KMail plug-in got a UI revamp. It now no longer looks like what was initially just supposed to be debug output, and its actions are now regular buttons rather than hidden in the not obvious to spot context menu.
KItinerary KMail plug-in with new UI visuals.
New KMail plug-in UI.

  • Timezones on Android so far were usually displayed as GMT offsets only. This is due to QTimeZone being limited to use older Android API for this. We now call newer Android API for this ourselves if available (API level >= 24), to get closer to the human readable timezone names we have on Linux.

  • Custom extractors for IndiGo, Flixbus, Lufthansa, RegioJet and ÖBB were added or improved, and the generic extractor for schema.org annotations in Microdata format can now handle nested objects correctly.

  • Calendar entries for restaurant reservations without an end time no longer span the entire day.

  • The trip group naming heuristic was improved to also consider the longest gap between location changes as the possible destination of a trip.

  • The KMail itinerary plug-in can now also show train classes, and can correctly display multiple ticket tokens now.

  • The KDE Itinerary app now shows inline feedback when importing data.

KDE Itinerary showing an inline notification about two successfully imported reservations.
KDE Itinerary providing feedback about imported reservations.

KPublicTransport, the framework that provides us with real-time transport data, also got a number of noteworthy improvements:

  • Backend services can now be configured with a static timezone. That’s used for backends that ignore timezones entirely due to being regionally restricted to just one anyway.

  • Backends can now indicate if they are able to query arrival times at a station, so the framework can avoid querying those on such requests.

  • The parser for responses from EFA backends now also supports an alternate compact response format that some services use.

  • The Hafas parser now resolves master location references, which should improve location query result quality a bit. Product selection in journey queries for Hafas-based backends was also fixed, which resulted in missing tram lines in certain locations.

  • A number of new backend services were added, covering Luxembourg as well as various regions in Austria, Germany and the US.

Deployment

All the development happening is of course of limited use if this isn’t distributed to our users. So I’d also like to highlight a few things supporting that:

  • As the KItinerary extractor engine depends on inofficial Poppler API, we need to regularly adapt that code to new Poppler releases. Besides doing that up to the upcoming 0.83 release of Poppler we hopefully also made the supporting infrastructure for this a bit more scalable and future proof, reducing the future maintenance effort there.

  • For deployment scenarios far away from our usual environments, such as old server systems, we have added the infrastructure to do full static builds of the command line extractor tool. That’s not necessarily a good alternative to proper distribution packages, but those aren’t easily available on say a Debian 9 server.

Contribute

This work continues to rely on donated data samples, thanks to everyone who has helped with this so far! And a special thank to the donator of the large set of multi-ticket samples that were essential in some of the above, there’s still much more work to be done based on that :)

If you want to help in other ways than donating test samples too, see our Phabricator workboard for what’s on the todo list, for coordinating work and for collecting ideas. For questions and suggestions, please feel free to join us on the KDE PIM mailing list or in the #kontact channel on Matrix or Freenode.