Re: KPublicTransport in kdereview
This has passed the two week mark, if there are no objections I'd move this to extragear/lib next week. Thanks, Volker On Saturday, 12 October 2019 12:54:31 CET Volker Krause wrote: > Hi, > > KPublicTransport has been moved to kdereview: > > https://phabricator.kde.org/source/kpublictransport/ > > KPublicTransport is a library for accessing real-time public transport > information (location, departure and journey queries) via a C++ or QML API, > aggregating results from Navitia.io as well as a few vendor-specific > backends. > > KPublicTransport originated inside KDE Itinerary but was split out at the > beginning of this year based on demand from KTrip. In order to get both apps > released eventually we need a release of KPublicTransport, therefore the > promotion out of playground now. > > While KPublicTransport aims to become a framework, it's not mature enough > for committing to API stability yet I think, so the more appropriate > destination for now would probably be extragear/lib I guess. Becoming part > of the release service once that is decoupled from the Applications product > would be very much appreciated though. > > At this point this is would be classified as a Tier 1 Functional framework, > I expect this to change though once we need translated strings, which will > become necessary for offering a way for the user to select which backends > to use. > > Regards, > Volker signature.asc Description: This is a digitally signed message part.
Re: KPublicTransport in kdereview
On Sunday, 13 October 2019 17:24:50 CEST Albert Astals Cid wrote: > El dissabte, 12 d’octubre de 2019, a les 12:54:31 CEST, Volker Krause va escriure: > > Hi, > > > > KPublicTransport has been moved to kdereview: > > > > https://phabricator.kde.org/source/kpublictransport/ > > > > KPublicTransport is a library for accessing real-time public transport > > information (location, departure and journey queries) via a C++ or QML > > API, > > aggregating results from Navitia.io as well as a few vendor-specific > > backends. > > > > KPublicTransport originated inside KDE Itinerary but was split out at the > > beginning of this year based on demand from KTrip. In order to get both > > apps released eventually we need a release of KPublicTransport, therefore > > the promotion out of playground now. > > > > While KPublicTransport aims to become a framework, it's not mature enough > > for committing to API stability yet I think, so the more appropriate > > destination for now would probably be extragear/lib I guess. Becoming > > part of the release service once that is decoupled from the Applications > > product would be very much appreciated though. > > Had a look, didn't find anything obviously wrong. > > The only thing is that the public API returns const & to vectors, which > we've historically not done since it ties you to having a vector internally > forever, but i'm fine accepting that > > Micro minor thing, clang tidy said > > src/backends/abstractbackend.cpp:199:16: error: the const qualified variable > 'headers' is copy-constructed from a const reference; consider making it a > const reference > [performance-unnecessary-copy-initialization,-warnings-as-errors] const > auto headers = netReply->rawHeaderPairs(); Thanks for reviewing, this has been fixed. Regards, Volker signature.asc Description: This is a digitally signed message part.
Re: KPublicTransport in kdereview
El dissabte, 12 d’octubre de 2019, a les 12:54:31 CEST, Volker Krause va escriure: > Hi, > > KPublicTransport has been moved to kdereview: > > https://phabricator.kde.org/source/kpublictransport/ > > KPublicTransport is a library for accessing real-time public transport > information (location, departure and journey queries) via a C++ or QML API, > aggregating results from Navitia.io as well as a few vendor-specific backends. > > KPublicTransport originated inside KDE Itinerary but was split out at the > beginning of this year based on demand from KTrip. In order to get both apps > released eventually we need a release of KPublicTransport, therefore the > promotion out of playground now. > > While KPublicTransport aims to become a framework, it's not mature enough for > committing to API stability yet I think, so the more appropriate destination > for now would probably be extragear/lib I guess. Becoming part of the release > service once that is decoupled from the Applications product would be very > much appreciated though. Had a look, didn't find anything obviously wrong. The only thing is that the public API returns const & to vectors, which we've historically not done since it ties you to having a vector internally forever, but i'm fine accepting that Micro minor thing, clang tidy said src/backends/abstractbackend.cpp:199:16: error: the const qualified variable 'headers' is copy-constructed from a const reference; consider making it a const reference [performance-unnecessary-copy-initialization,-warnings-as-errors] const auto headers = netReply->rawHeaderPairs(); Cheers, Albert > > At this point this is would be classified as a Tier 1 Functional framework, I > expect this to change though once we need translated strings, which will > become necessary for offering a way for the user to select which backends to > use. > > Regards, > Volker > >
KPublicTransport in kdereview
Hi, KPublicTransport has been moved to kdereview: https://phabricator.kde.org/source/kpublictransport/ KPublicTransport is a library for accessing real-time public transport information (location, departure and journey queries) via a C++ or QML API, aggregating results from Navitia.io as well as a few vendor-specific backends. KPublicTransport originated inside KDE Itinerary but was split out at the beginning of this year based on demand from KTrip. In order to get both apps released eventually we need a release of KPublicTransport, therefore the promotion out of playground now. While KPublicTransport aims to become a framework, it's not mature enough for committing to API stability yet I think, so the more appropriate destination for now would probably be extragear/lib I guess. Becoming part of the release service once that is decoupled from the Applications product would be very much appreciated though. At this point this is would be classified as a Tier 1 Functional framework, I expect this to change though once we need translated strings, which will become necessary for offering a way for the user to select which backends to use. Regards, Volker signature.asc Description: This is a digitally signed message part.
