Gitlab updates completed

2020-10-23 Thread Ben Cooksley
Hi all,

This morning i've completed updates to our Gitlab instance at invent.kde.org,
bringing us up to Gitlab 13.5.

Details on the new functionality and major bugs fixed can be found at
https://about.gitlab.com/releases/2020/10/22/gitlab-13-5-released/

Please note that as we use the Community Edition of Gitlab, only features
shown as being in 'Core' are available to us.

Regards,
Ben Cooksley
KDE Sysadmin


Re: plasma-systemmonitor in kdereview

2020-10-23 Thread Arjen Hiemstra
On Friday, 2 October 2020 17:10:36 CEST Carl Schwan wrote:
> 
> Plasma System Monitor looks quite good, but it doesn't look like it is
> navigable with the keyboard only. I know that some of the issues are caused
> by Kirigami and Qml but it looks like many custom components can't get any
> focus with tab and need the mouse to work.
> 

As an update to this, I did a first pass to improve keyboard navigation, now in 
"view" mode things should work correctly, with everything that should get 
focus receiving focus, including the applications table on the overview page. 
As said before, the edit mode is a different beast and we're not yet entirely 
sure how to handle keyboard for that.

- Arjen






Re: plasma-systemmonitor in kdereview

2020-10-23 Thread Arjen Hiemstra
On Monday, 19 October 2020 00:28:38 CEST Albert Astals Cid wrote:
> How serious are these cmake warnings? http://paste.debian.net/1167754/

I've seen those before; apparently the result is that there's no autogenerated 
appdata for the sensor faces. Not sure how important that is to be honest. At 
least the package itself installs properly.

> I'd personally would suggest to remove these default values from 
KillDialog.qml

Done in [1]

> I guess i'm running a too old version of some dependency?
>  
> "file:///home/tsdgeos/devel/kde/install/share/ksysguard/sensorfaces/org.kde
> .ksysguard.processtable/contents/ui/FullRepresentation.qml:127:18:TypeProces
> sTableViewunavailable"
> "file:///home/tsdgeos/devel/kde/install/share/ksysguard/sensorfaces/org.kde
> .ksysguard.processtable/contents/ui/ProcessTableView.qml:97:9:Cannotassignto
> non-existentproperty\"flatList\"" Would make sense to mark that in the
> cmakelists you think? or is it just supposed to be used with plasma master
> in sync?

Actually, the intention was to be able to build against Plasma 5.20. The tree 
view support bits were only added in master though and we apparently forgot to 
check that it still works with 5.20. I've fixed that also in [1]

[1]: https://invent.kde.org/plasma/plasma-systemmonitor/-/merge_requests/56




Re: KOSMIndoorMap in kdereview

2020-10-23 Thread Albert Astals Cid
El divendres, 23 d’octubre de 2020, a les 16:56:37 CEST, Volker Krause va 
escriure:
> On Freitag, 23. Oktober 2020 00:45:46 CEST Albert Astals Cid wrote:
> > 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.)
> 
> fixed, although that requires modifying the 3rdparty proto files
> 
> > 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;
> 
> both fixed
> 
> > Should ./bin/indoormap do anything? I have one empty combo and one combo
> > that lets me change the style.
> 
> Good point, I've documented the test apps in the README now. Try `indoormap 
> -c 
> 52.52512,13.36966` or alternatively `qmlscene tests/indoormap.qml` to see a 
> few more features (after updating to latest master to make this work with 
> your 
> locale too, see below).
> 
> > You have one qsTr in the qml that it's not going to work, also a "TODO
> > i18n?" that i would say yes?
> 
> Fixed, leftovers from before switching to ki18n.

Since i understand this is a library, you want to use i18nd on qml (you're 
using that on your c++ by using -DTRANSLATION_DOMAIN=)

> 
> > It has tests \o/ the tests don't pass /o\ https://pastebin.com/CFcdVJHh
> 
> Ouch, you actually found some quite serious breakage that I had entirely 
> missed since neither my local nor the CI locale is affected... This all goes 
> down to some string to floating point number conversion being done locale-
> aware while they shouldn't be.

Glad to be of service :)

Another thing, do you want d-pointers to make keeping ABI easier or don't care 
at this point?

Cheers,
  Albert


> 
> Dirty fixes applied, once std::from_chars becomes available for floating 
> point 
> types this can be addressed more cleanly.
> 
> We should run the CI with rotating/random locales :) 
> 
> Thanks for the feedback!
> Volker
> 
> 
> 
> 






Restriction on bulk and automated changes to Git repositories

2020-10-23 Thread Ben Cooksley
Hi all,

As some of you will be aware, over the past week KDE.org infrastructure has
experienced some issues with services being overloaded by automated bots.
Coupled with a series of bulk changes that developers have pushed over the
past week, this has left us with some cleanup work that needs to be
performed.

To allow for necessary cleanup work from this to be conducted cleanly,
quickly and efficiently, we need to temporarily restrict the types of
changes that developers make.

As such, for the next 3 days (covering the period 24 - 26 October 2020),
performing bulk changes of any form to KDE Git repositories is prohibited.
Bulk change is defined as affecting more than 1 repository with the same or
similar change in a short period of time.

This includes changes such as version and dependency bumps, code style
cleanups, renames, adding of configuration files, and any other change that
is repeatable across multiple repositories in an automated manner.

No exception is given to release preparation activities, and any release
that would require the above to be performed should be considered to have
been postponed.

Regards,
Ben Cooksley
KDE Sysadmin


Re: KOSMIndoorMap in kdereview

2020-10-23 Thread Volker Krause
On Freitag, 23. Oktober 2020 00:45:46 CEST Albert Astals Cid wrote:
> 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.)

fixed, although that requires modifying the 3rdparty proto files

> 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;

both fixed

> Should ./bin/indoormap do anything? I have one empty combo and one combo
> that lets me change the style.

Good point, I've documented the test apps in the README now. Try `indoormap -c 
52.52512,13.36966` or alternatively `qmlscene tests/indoormap.qml` to see a 
few more features (after updating to latest master to make this work with your 
locale too, see below).

> You have one qsTr in the qml that it's not going to work, also a "TODO
> i18n?" that i would say yes?

Fixed, leftovers from before switching to ki18n.

> It has tests \o/ the tests don't pass /o\ https://pastebin.com/CFcdVJHh

Ouch, you actually found some quite serious breakage that I had entirely 
missed since neither my local nor the CI locale is affected... This all goes 
down to some string to floating point number conversion being done locale-
aware while they shouldn't be.

Dirty fixes applied, once std::from_chars becomes available for floating point 
types this can be addressed more cleanly.

We should run the CI with rotating/random locales :) 

Thanks for the feedback!
Volker





Re: KOSMIndoorMap in kdereview

2020-10-23 Thread Volker Krause
On Donnerstag, 22. Oktober 2020 21:14:43 CEST Rolf Eike Beer wrote:
> 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.

fixed

> 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.

Since the vectors are sorted, lookup performance there hasn't been an issue so 
far. Lookup performance for tags OTOH has been (and to some extend still is) a 
much bigger issue.

> 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.

Right, a common base class and virtual methods would make that code more 
elegant, possibly even making the entire Element/UniqueElement classes 
unnecessary. However, that comes at the cost of an extra sizeof(void*) per 
instance. And given how many instances there are and how aggressively this has 
been optimized for memory size, that would be going in the wrong direction. 
I've actually thought about adding an additional type for the common case of 
tag-less nodes to get rid of the tag storage overhead in that case :)

While this is designed to handle a single (large and detailed) building only, 
it can actually handle an entire city as well by now, without any tiling. That 
should leave us enough room even in case of an exploding level of detail in 
large train stations, and for resource-constraint phones.

Q_UNREACHABLEs have been added.

> The nodes vectors in Element::outerPath() could benefit from a call to
> reserve().

appendNodesFromWay() (and via that also assemblePath()) do call reserve on 
those vectors internally.

> 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.

fixed

> Eike

Thanks for the feedback!

Volker





Re: Peruse in KDEReview

2020-10-23 Thread Dan Leinir Turthra Jensen
On Wednesday, 21 October 2020 11:39:32 BST Dan Leinir Turthra Jensen wrote:
>   Just under a month since that reminder above went out, so i thought i'd
> give a quick poke and say that unless i hear opinions otherwise, i'll
> consider this an agreement that things are in decent order, and i will move
> Peruse to its new home in extragear/graphics/peruse on Friday the 23rd of
> October (that is, in two days). Thanks for the comments people have already
> made, too, while of course they were not super numerous, they were
> constructive and encouraging!

  As forewarned, the move has now been completed. Thank you again to those who 
commented, highly useful and helpful stuff from everybody :)

https://invent.kde.org/sysadmin/repo-metadata/commit/
e71a98b28f0f73c208c29086617b335b722f8190
-- 
..dan / leinir..
http://leinir.dk/