Subclasses should use this method instead of directly calling
QString::contains or using Python 's in search' type matches.
This ensures consistent matching behaviour across different filters.
Filters can indicate their preferred search prefix. Searches which
begin with this character will be restricted to the single matching
filter.
E.g. entering 'l buffer' will searching only layers containing 'buffer'
Other prefixes are:
- . search actions
- pl search print layouts
- a search algorithms
Plugins are restricted to a minimum 3 character prefix. We do this
to avoid plugins 'stealing' desirable prefixes, and instead we
want to reserve them for future core filters.
Higher priority (i.e. more important) filter results get shown
first. This means filters like project layers & composers will
show above 'cruder' filters like the actions/processing filters.
This allows encapsulation of properties relating to the context
of a search, such as a target map extent. Locator filters could
use this to prioritise results close to the current canvas extent.
The project layer filter allows you to quickly select a layer
from the current project and highlight it in the layer tree.
It's useful for complex project with lots of groups, where
it's easy to "lose" layers somewhere in the tree...
The composition filter allows searching for and opening
compositions from the current project
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
This reverts commit e3d79a1fe940b5d813b5f79c51b43393d085bb16, reversing
changes made to 3f7f95ee262ea3646d61600c21faed0866bc70b0.
Reverting again, as Travis started failing after merging PR (with all
test passed) into master branch
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.
This allows gui widgets to utilise native platform interfaces.
Additionally attaching the instance to QgsGui allows QgsNative
to become a QObject in future if required and for use
of signals/slots in the native interfaces.
