This option was being applied in the wrong place - within the
map layer classes themselves. This meant that depending on the
user's setting for this option, a plugin calling QgsMapLayer::setName
would not be guaranteed the same behaviour across installs.
(and the same with setDataSource)
Similarly, the option was re-applied on project load, so
moving projects between installs with different values for
this setting would affect the project layer names, breaking
expressions which relied on these...
Instead, move the formatting and capitalization of layer
names to the QgisApp add*Layer methods instead, so this option
only applies on adding new layers to a project.
...by moving extra arguments to new LayerOptions structs. This allows
us to more easily add new layer constructor options without making
the API cumbersome to use.
- Remove QgsSvgCacheEntry from public API (is an internal detail only)
- Modernize code
- Make protected QgsSvgCache members private, since this class is not
designed to be subclassed
- QgsGeometry::fromPoint() was renamed to fromPointXY()
- QgsGeometry::fromMultiPoint() was renamed to fromMultiPointXY()
- QgsGeometry::fromMultiPolyline() was renamed to fromMultiPolylineXY()
- QgsGeometry::fromPolygon() was renamed to fromPolygonXY()
- QgsGeometry::fromMultiPolygon() was renamed to fromMultiPolygonXY()
Previously the method in QgsGeometryUtils was relying on
QgsAbstractGeometry::coordinateSequence, which is an absolute
performance killer.
Instead move to optimised methods in the various abstract
geometry subclasses which rely only on trivial calculations.
and add new QgsGeometry::fromPolyline which uses QgsPoint
We want to encourage people not to use the QgsPointXY method, as it drops
Z/M values. So it's moved across to a different name to make way
for a new QgsGeometry::fromPolyline which uses a QgsPoint list
instead of QgsPointXY, thus keeping Z/M values intact.
Similarly, QgsPolyline now is a list of QgsPoint (keeping z/m values)
and the old 2d QgsPolyline type was renamed to QgsPolylineXY.
Making the QgsPoint method the "preferred" method and making linestrings
just as easy to create from z/m dimensioned points as 2d points is
important to push people to write code which does not discard
these important dimensions.
As a bonus, the QgsPoint methods are more efficient anyway, since
they don't require creation of a temporary list.
