While the processing API is in such a state of flux it's
become unmaintainable to port these algorithms change-by-change.
Instead, disable them all until the API is fixed, and then we
can port them algorithm by algorithm and reactivate each
test in turn.
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 reverts commit e3d79a1fe940b5d813b5f79c51b43393d085bb16, reversing
changes made to 3f7f95ee262ea3646d61600c21faed0866bc70b0.
Reverting again, as Travis started failing after merging PR (with all
test passed) into master branch
Since the majority of users of this class will be exporting
an existing map layer to a data provider, the QgsVectorLayerImport
name is misleading and suggests that this class is designed
just to bring layers "into" QGIS.
Explicitly naming the class "Exporter" should help API users
discover this class.
Also cleanup API and improve docs
This implements an improved version of vector.createVectorWriter
in QgsProcessingUtils. The improved version relies on the
core class QgsVectorLayerImport to create empty layers,
which:
- reduces duplicate code and reuses the mature QgsVectorLayerImport
routines
- avoids manual conversion of field types to destination provider
field types
- potentially allows any writable provider to be used as a feature
sink for algorithms (e.g. output direct to MSSQL/Oracle/db2). This
should work now - it just needs exposing via UI.
- provider() was renamed to createProvider()
- selectWidget() was renamed to createSelectionWidget()
- providerLibrary() was renamed to createProviderLibrary()
