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.
instead of adding an extra CMakeLists in .ci/travis/code_layout to build API doc, astyle and run tests (indentation, spelling, sip, doc coverage), the top CMakeLists has been adapted to allow not building core libraries and possibly just the static code layout
* astyle has been moved from /src/astyle to /lib/astyle (I would propose to move all external libraries, and possibly add git submodules)
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 adds a new "locator" bar to the QGIS status bar. If you're not
familiar with QtCreator's locator, it's a quick search bar
(activated by Ctrl+K) which displays matching search results
from any number of registered search filters.
Search filters are subclassed from QgsLocatorFilter, and
added to the app's locator via iface.registerLocatorFilter(...)
Searching is handled using threads, so that results always
become available as quickly as possible, regardless of whether
any slow search filters may be installed. They also appear
as soon as each result is encountered by each filter, which means
that e.g. a file search filter will show results one by one
as the file tree is scanned. This ensures that the UI is always
responsive even if a very slow search filter is present (e.g.
one which uses an online service).
This framework is designed to be extended by plugins, such as
OSM nominatim searches, direct database searching (i.e. Discovery
plugin), layer catalog searches, etc...
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.
