Re: KOSMIndoorMap in kdereview
El dijous, 22 d’octubre de 2020, a les 17:25:32 CEST, Volker Krause va escriure: > Hi, > > KOSMIndoorMap is a QML component for showing multi-floor OSM indoor maps (as > its very creative name might suggest). It's using maps.kde.org as a data > source (same as Marble), and has been created to show interactive maps of > train stations for KDE Itinerary. > > https://invent.kde.org/libraries/kosmindoormap > > KOSMIndoorMap has been growing inside the KPublicTransport repo (due to some > building blocks being available there alreay and me being lazy), and has now > been split into its own repo. So technically this is coming out of a reviewed > repo already rather than from playground, but better be on the safe side :) > > The aim is having this (together with KPublicTransport and KDE Itinerary) > join > the release service for 20.12. > Is this fixable? [libprotobuf WARNING google/protobuf/compiler/parser.cc:648] No syntax specified for the proto file: osmformat.proto. Please use 'syntax = "proto2";' or 'syntax = "proto3";' to specify a syntax version. (Defaulted to proto2 syntax.) [libprotobuf WARNING google/protobuf/compiler/parser.cc:648] No syntax specified for the proto file: fileformat.proto. Please use 'syntax = "proto2";' or 'syntax = "proto3";' to specify a syntax version. (Defaulted to proto2 syntax.) and this? style/mapcsslexer.l:65: warning, no es pot satisfer la regla style/mapcssparser.y:143.11-14: advertiment: valor sense usar: $2 [-Wother] 143 | | Ruleset Rule | ^~~~ and this? src/map/scene/scenegeometry.cpp: In function ‘double KOSMIndoorMap::SceneGeometry::polylineMidPointAngle(const QPolygonF&)’: src/map/scene/scenegeometry.cpp:75:24: warning: unused variable ‘r’ [-Wunused-variable] 75 | const auto r = ((length + l) - lineLength / 2.0) / l; Should ./bin/indoormap do anything? I have one empty combo and one combo that lets me change the style. You have one qsTr in the qml that it's not going to work, also a "TODO i18n?" that i would say yes? It has tests \o/ the tests don't pass /o\ https://pastebin.com/CFcdVJHh Cheers, Albert > Thanks, > Volker > > > >
Re: MacOS signing issue.
Thanks. I will be updating and closing the issue since I have no control over any of this. On Thu, Oct 22, 2020, 1:15 PM Jeremy Whiting wrote: > Notarizing and signing are actually separate things on MacOS, signing the > app or checking the signature of the dmg are orthogonal to the issue > described and the popup in that report. Notarization is sending the app > (zipped) to apple's notarization service so they can check it doesn't use > any apis that it shouldn't or something, then the .app needs to be > "stapled" with the notarization before putting it into the dmg. That said > iirc signing the app is a requirement before submitting the app to apple's > notarization service in the first place. > > On Thu, Oct 22, 2020 at 11:12 AM Ben Cooksley wrote: > >> On Fri, Oct 23, 2020 at 6:08 AM Michael Reeves >> wrote: >> >>> Could someone familiar with the CI and OS X signing machinism look at >>> this. >>> >>> https://bugs.kde.org/show_bug.cgi?id=428062 >>> >>> I have no way to test or fix this issue. Which as far as I know is an >>> issue with the CI on binary factory. >>> >> >> This is because Craft to my knowledge at this time does not support >> notarization of MacOS binaries. >> >> Once that has been added, the issue should disappear. >> >> Regards, >> Ben >> >
Re: MacOS signing issue.
Thanks. On Thu, Oct 22, 2020, 1:15 PM Jeremy Whiting wrote: > Notarizing and signing are actually separate things on MacOS, signing the > app or checking the signature of the dmg are orthogonal to the issue > described and the popup in that report. Notarization is sending the app > (zipped) to apple's notarization service so they can check it doesn't use > any apis that it shouldn't or something, then the .app needs to be > "stapled" with the notarization before putting it into the dmg. That said > iirc signing the app is a requirement before submitting the app to apple's > notarization service in the first place. > > On Thu, Oct 22, 2020 at 11:12 AM Ben Cooksley wrote: > >> On Fri, Oct 23, 2020 at 6:08 AM Michael Reeves >> wrote: >> >>> Could someone familiar with the CI and OS X signing machinism look at >>> this. >>> >>> https://bugs.kde.org/show_bug.cgi?id=428062 >>> >>> I have no way to test or fix this issue. Which as far as I know is an >>> issue with the CI on binary factory. >>> >> >> This is because Craft to my knowledge at this time does not support >> notarization of MacOS binaries. >> >> Once that has been added, the issue should disappear. >> >> Regards, >> Ben >> >
Re: KOSMIndoorMap in kdereview
Am Donnerstag, 22. Oktober 2020, 17:25:32 CEST schrieb Volker Krause: > Hi, > > KOSMIndoorMap is a QML component for showing multi-floor OSM indoor maps (as > its very creative name might suggest). It's using maps.kde.org as a data > source (same as Marble), and has been created to show interactive maps of > train stations for KDE Itinerary. > > https://invent.kde.org/libraries/kosmindoormap > > KOSMIndoorMap has been growing inside the KPublicTransport repo (due to some > building blocks being available there alreay and me being lazy), and has > now been split into its own repo. So technically this is coming out of a > reviewed repo already rather than from playground, but better be on the > safe side :) > > The aim is having this (together with KPublicTransport and KDE Itinerary) > join the release service for 20.12. The const version of DataSet::way() returns Way*, but the non-const version returns OSM::Way*. I guess the extra qualification is not needed. In OSM2go I use std::unordered_map to store the different types of objects which makes lookups much easier. YMMV depending if you want to optimize for lookup or memory size. My recent work there is to get rid of the note, way, and relation prefixes or suffixes on function names and make a template from the remaining implementation so I don't have to implement the same things 3 times. I have derived all 3 object types from a common base class, which allows me to simplify things like Element::url() by just calling obj->url() and let a virtual overload do the rest. Which is a good example: the final return in that function should be replaced by Q_UNREACHABLE(), too. The nodes vectors in Element::outerPath() could benefit from a call to reserve(). The coding style for the remark-if in XmlParser::parse() is inconsistent. Or, if compared to the rest of the file, it's the only consistent one in that function. Eike signature.asc Description: This is a digitally signed message part.
Re: MacOS signing issue.
Notarizing and signing are actually separate things on MacOS, signing the app or checking the signature of the dmg are orthogonal to the issue described and the popup in that report. Notarization is sending the app (zipped) to apple's notarization service so they can check it doesn't use any apis that it shouldn't or something, then the .app needs to be "stapled" with the notarization before putting it into the dmg. That said iirc signing the app is a requirement before submitting the app to apple's notarization service in the first place. On Thu, Oct 22, 2020 at 11:12 AM Ben Cooksley wrote: > On Fri, Oct 23, 2020 at 6:08 AM Michael Reeves > wrote: > >> Could someone familiar with the CI and OS X signing machinism look at >> this. >> >> https://bugs.kde.org/show_bug.cgi?id=428062 >> >> I have no way to test or fix this issue. Which as far as I know is an >> issue with the CI on binary factory. >> > > This is because Craft to my knowledge at this time does not support > notarization of MacOS binaries. > > Once that has been added, the issue should disappear. > > Regards, > Ben >
Re: MacOS signing issue.
On Fri, Oct 23, 2020 at 6:08 AM Michael Reeves wrote: > Could someone familiar with the CI and OS X signing machinism look at this. > > https://bugs.kde.org/show_bug.cgi?id=428062 > > I have no way to test or fix this issue. Which as far as I know is an > issue with the CI on binary factory. > This is because Craft to my knowledge at this time does not support notarization of MacOS binaries. Once that has been added, the issue should disappear. Regards, Ben
MacOS signing issue.
Could someone familiar with the CI and OS X signing machinism look at this. https://bugs.kde.org/show_bug.cgi?id=428062 I have no way to test or fix this issue. Which as far as I know is an issue with the CI on binary factory.
KOSMIndoorMap in kdereview
Hi, KOSMIndoorMap is a QML component for showing multi-floor OSM indoor maps (as its very creative name might suggest). It's using maps.kde.org as a data source (same as Marble), and has been created to show interactive maps of train stations for KDE Itinerary. https://invent.kde.org/libraries/kosmindoormap KOSMIndoorMap has been growing inside the KPublicTransport repo (due to some building blocks being available there alreay and me being lazy), and has now been split into its own repo. So technically this is coming out of a reviewed repo already rather than from playground, but better be on the safe side :) The aim is having this (together with KPublicTransport and KDE Itinerary) join the release service for 20.12. Thanks, Volker
