GitLab

Forward declaration seems not to be enough for MSCV

See https://binary-factory.kde.org/view/Windows%2064-bit/job/KTrip_Nightly_win64/447/console

Both GBFS and OTP provide that distinction (at least somewhat), and now we
can actually represent that.

Unfortunately this cannot be queried online, but needs to be dug out of
server-side config files.

This enables a number of things though:
- filter static dummy networks that e.g. stadtnavi uses to provide
locations for taxis or car sharing.
- translate the internally used identifiers to human readable names.
- provide vehicle type default values for single-type networks, so we can
show appropriate icons etc.
- map identifiers to GBFS feeds where we have those available as well, to
support result merging.

We also still need to add this data to the other OTP instances supporting
rental vehicles (eg. those in Finland).

This is still producing wrong types for ride sharing journeys, but that's
needing either a change in the GraphQL query, or client-side heuristics,
the current response doesn't contain that distinction.

Vaguely following the MDS/GBFS model (but still vastly simplified for now).
While initially motivated by better support bike sharing in OTP backends,
it's seems likely we can actually build a generic GBFS-based client as
well.

Departure was always a poor name, given it is also used for arrivals.
Things got worse with this now also being used for intermediate stops,
which are both arrivals and departures at the same time. Finding a good
alternative name is tricky though, as many candidates are ambiguous
regarding stop locations ("stop", "halt", etc). Digitransit uses the
words "call" and "quay" to distinguish this, but while clear those are
rather niche terms. FPTF uses "stopover" for this, which seems like a
decent compromise.

This is only the first step in adjusting the entire API accordingly,
more classes will follow, while trying to keep source compatibility.

Departure result parsing is still to be done though.

They use almost the same reply format, so we can already parse journey
query replies from the REST API, but we still need to implement the other
query types.

Needed for parsing OTP responses.

This approach works ok-ish, but:
- alternating background colors for multi-class coaches don't work with
the BorderIcon approach at all
- platform length ideally should be normalized somehow, the same train can
look very different in different stations

That is, query coach layouts of a train, as well as where they will stop
on a platform. This information is available at varying degree of detail
at least for German and Indian long distance railways it seems.

Nothing actually working yet, just the empty shell.

It's actually only needed in the implementation, and not for each usage of
Q_DECLARE_PUBLIC. This avoids conflicting with other libraries having a
similar helper function.

Fixes ODR violation when needing this in a second class hierarchy.

Summary: Move the type registration from Itinerary into a proper qml plugin so it can be used everywhere

Reviewers: vkrause

Reviewed By: vkrause

Differential Revision: https://phabricator.kde.org/D22411

This just contains barely enough data model and backend access code to
search for a journey between two locations. Most notably this still misses
a frontend API that hides the various low-level REST calls behind a
job-like interface.

This is prepared to eventually become a standalone framework, it's useful
beyond just this application.