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.
main window statusbar
QStatusBar gives almost no control over display and placement
of child widgets. It's not possible to subclass and reimplement
either, due to how QMainWindow works internally, and also due to
the special handling for the size grip and other platform specific
handling in QStatusBar.
Instead, we embed a single QgsStatusBar covering the whole real
status bar. All child widgets and temporary messages instead
are pushed to the QgsStatusBar instead - giving us as much control
as we desire over how these widgets are placed and their behavior.
As a result the locator widget has been moved to its logical placement
on the left of the status bar.
All plugins must ensure that they use the status bar interface
available via iface.statusBarIface() instead of directly interacting
with the status bar (e.g. iface.mainWindow().statusBar()...)
This is a completely wrong use of an algorithm that is meant to be used with *integer* values,
e.g. when dealing with pixels on screen, but not for coordinates that are floating point numbers.
The algorithm has a fixed tolerance of 1 unit.
QgsPoint(5,0.9).onSegment(QgsPoint(0,0), QgsPoint(10,0)) would return 2 (i.e. point is on line segment)
See the original code: https://github.com/erich666/GraphicsGems/blob/master/gems/PntOnLine.c
Historically the configuration used to be stored in layer's custom properties, but that does not scale
beyond simple rendering and so rule-based labeling introduced storage of configuration natively in XML elements.
That left us with two different ways of reading/writing labeling configurations. This work makes all configuration
to use native XML elements.
To keep compatibility of 2.x projects, reading of configuration from custom properties is preserved.
This commit also adds Python APIs for direct manipulation of labeling configuration through vector layer's
setLabeling() and labeling() calls.
