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...
