Because:
- it's unused in master, and is more code to maintain
just for possible use by plugins
- it's unmaintained, and has had no work done (beside compilation
fixes) in the recent past
- there's no unit tests or detailed documentation to show
how the class should be used
Instead of just forcing writing the triangulation to a shapefile (boo!)
change the parameter to use a QgsFeatureSink, so that anything
which implements the QgsFeatureSink interface can be used for
storing the triangulation.
These classes still need a lot of cleanup (e.g. use of proper
3d geometry classes instead of their own 3d line classes, etc)
and we don't want them locked into the 3.0 API.
Better to remove them from the API and reintroduce them after
they have been cleaned up (in >3.0). They are mostly implementation
details anyway, and unlikely to be used outside of the high
level interpolation classes.
It was slightly confusing to have another override for snapping while it is possible
to configure "no snapping" or "all layers" snapping mode in project anyway.
And with the nice snapping toolbar it can be also done very quickly.
These classes are unused in the master QGIS code, and are
unmaintained and with no unit tests or other QA, and
have inflexible API (e.g. always requiring writing outputs
to shapefiles)
They all have equivalent algorithms available via Processing
(where the algorithms are unit tested and maintained). We should
be pushing all QGIS api users to use the Processing algorithms
instead.
It makes no sense to have two classes covering this use case, with
partial functionality in each. Smash the two together so we can
safely use QgsFileWidget for all use cases in future.
Flip all scale based widgets to use scale denominators instead
of actual scales (ie 100.0 instead of 0.01 for 1:100).
This is done for consistency with the rest of the API, which
predominantly uses scale denominators. It also helps
precision loss as a result of multiple 1.0 / scale conversions
throughout the code.
Refs #15337
I have got caught by the default set to WGS 84 when I loaded a layer
in projected CRS, set extent to layer's extent and... nothing got rendered
because map renderer was reprojecting to WGS 84.
This default is closer to the default in 2.x where reprojection is turned off.
setMaximumScale() and setMinimumScale(), maximumScale() and
minimumScale() had the opposite meaning to other min/max scales
in the API, and were the opposite to how these settings were
exposed in the GUI. This lead to very confusing API!!
Their definitions have now been swapped. setMaximumScale
now sets the maximum (i.e. largest scale, or most zoomed in)
at which the layer will appear, and setMinimumScale now sets
the minimum (i.e. smallest scale, or most zoomed out) at
which the layer will appear. The same is true for the
maximumScale and minimumScale getters.
