When nodes of a building are tagged with house numbers, render them.

The Vector OSM map theme has some rendering order problems right now
that result in some item combinations to look odd. This patch provides
a more fine-granular control of the rendering order. It also refactors
the decorators previously used and merges them into that approach.

Extend paint() of GeographicsItem to take another argument, a string
layer
Each GeographicsItem specifies a list of such layers it wants to paint
GeometryLayer defines the order of layers and paints them that way
E.g. currently a highway behaves like this:

GeoLineStringItem is created, and internally creates a copy of itself
which is its decorator, assigns a z-value
GeometryLayer queries all decorators during paint, sorts them by z-value
GeoLineStringItem tests whether it is a decorator during painting,
changes rendering based on that
The patch changes this to

GeoLineStringItem is created and asks for three layers to be rendered:
.../outline, .../inline and .../label
GeometryLayer queries all layers during paint, sorts them by render
order
GeoLineStringItem changes rendering based on the provided layer name
This avoids having to treat decorators as special and duplicated items
internally, and also allows an important render order behavior change:
It is now possible to render e.g. all visible streets first and all
their labels afterwards. Previously it was only possible to render one
street after the other, so e.g. the second street could overpaint the
label of the first.

Projects: #marble

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

When a completion has no results, a longer query starting with the same
string as the failing one cannot have any results (as long as the model
has not changed under the hood). Do not search in this case.

This speeds up the common case when the user keeps on typing for a
search string when the completion runs out of results, or hits backspace
repeatedly in the same case.

Lighter, invisible when not moving, DPI aware width, clipped.

Member variables are destroyed in reverse order of appearance. When
the tile cache is destructed, the shared pointers of its documents
can reach zero and will attempt to remove themselves from the tree
model. While doing so the garbage queue and the list of pending
documents is checked, so they need to be intact at this point. This
is only the case if the tile cache appears after the garbage queue
and the list of pending documents in the member variables list.

Render higher buildings on top of lower ones. This gives a slightly
better impression than using a random order like before.

Summary:
In OpenStreetMaps, the placemarks are now shown in the local language of the viewer, provided that proper mapping of that language is available. If no mapping is found, the local name of the placemark is shown.

Working:
1. Determines the language code of the placemark.
2. Determines the language of the viewer in order of preference.
3. Chooses the best translation alternative and displays that.

{F45339}

Reviewers: #marble, nienhueser

Subscribers: #marble, nienhueser

Projects: #marble

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

Summary:
QtQml 5.3 seems to need this even for passing just Marble::MarbleMap* values
between objects, without accessing any properties of Marble::MarbleMap

Reviewers: nienhueser

Reviewed By: nienhueser

Projects: #marble

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

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

Summary:
Fixed:
- After moving from files.kde.org to maps.kde.org the elevation profile
  data in the srtm2 map theme failed to download.
- After moving to maps.kde.org all queries to tiles on files.kde.org
  caused another http lookup to process the redirect.

Old DGML files keep working, but there is more flexibility now: MarbleServerLayout can be used and still override the server URL and the path. I wonder however if this kind of flexibility is useful?

Reviewers: #marble, rahn

Subscribers: #marble

Projects: #marble

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

Both QThreadPool and ParsingRunnerManager were trying to delete the
same class instance. Now ParsingRunnerManager only keeps track of
the number of active parsers, but does not attempt to delete them
once they finish.

A simpler fix would have been to call setAutoDelete(false) in the
ParsingTask ctor, but this approach seems cleaner.

CCBUG: 357157