Previously this was only enabled for optional arguments (i.e.
those with default values). Enabling them for all arguments
allows for more readable PyQGIS code, and there seems no
downside given that we already have this support partly enabled.
The consequence of this change is that when 3.0 API is frozen
the freeze must also include the naming of function arguments,
since that's effectively now part of public API.
These classes are used for storing measurements for a layout
(QgsLayoutMeasurement), sizes for a layout (QgsLayoutSize)
and points in a layout (QgsLayoutPoint)
They support storing a measurement unit alongside a measurement
length/size. A new class QgsLayoutMeasurementConverter handles
conversion between different units, including converting to and
from pixels via a specified DPI property.
Instead of having different marker sizes in legend as separate legend nodes,
the new "collapsed" mode packs all sizes into one legend node.
This commit only makes it available in the API, not exposed in GUI yet.
This somewhat changes the meaning of outputs from processing 2.x.
In 2.x processing outputs were used both as a method of specifying
inputs to algorithms (file paths to destination layers created
by the algorithm) AND pure outputs (such as statistics calculated
by the algorithm).
This is now split. The old input-type-outputs (destination layers)
are now input parameters (since the parameter value IS an input to the
algorithm). To differentiate them from parameters indicating pure
input layers a new "isDestination()" method was added to
QgsProcessingParameterDefinition.
Output definitions are now purely indications of values CREATED
by the algorithms. Suitable candidates are the existing calculated
stats and actual file path/URI of any layers created by the algorithm.
Moving forward we should ensure all algorithms output as much
useful information as possible - e.g. number of features processed,
number of skipped features, count null geometries encountered, etc...
The file qgsexpressions.h has grown to one monolithic piece over the
years. This makes it hard to maintain and slows down compilation because
even small changes at one end will result in recompiling big parts of
the source tree. It also requires the compiler to keep track of all
these implementation details for said big parts of the source tree.
This splits this implementation into smaller pieces. There are soe API
changes connected to this, but since these can be considered
implementation details, on which not many plugins rely, this shouldn't
have a big impact on the ecosystem outside the source tree.
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.
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 commit adds the virtual method for running processing algs
to the base c++ class, and adds the initial framework
for c++ algorithm parameters.
When running an algorithm, a QVariantMap is passed
as the algorithm parameters. The high level API provided
by QgsProcessingParameters should be used to retrieve
strings/layers/doubles/etc from this QVariantMap.
This allows advanced use cases, such as passing QgsProperty
with the QVariantMap for "dynamic" parameters, where the
value should be evaluated for every feature processed.
E.g. if the buffer algorithm uses a dynamic property for distance,
then the distance could be bound to either a field value or
to a custom expression. This gets evaluated before buffering
each feature to allow for advanced variable buffering.
Support for dynamic parameters will be "opt in", and non default.
So algorithms will need to specifically add support for
dynamic properties as required.
The geometry cache was only used for few geometry editing operations anyway. In earlier versions
of QGIS the geometry cache was also used by old snapping classes which have been replaced
by QgsPointLocator that also keeps a spatial index of geometries and it is not rebuilt on every re-render.
Reasons for removal:
- geometry cache was repopulated on every redraw of layers in editing mode, slowing down rendering
- data structure for the cache was a simple map with features accessed by their ID (no spatial index)
- the cache was only getting refreshed for the current view of the main map canvas (not a generic cache)
- not used for snapping anymore where caching was important to avoid roundtrips to data provider
of new memory layers from QgsFields/QgsCoordinateReferenceSystem/etc
Since memory provider cannot use QgsVectorLayerImport we need
another centeralized function for creating new memory layers
without the need to manually create the uri string.
Adds a new abstract base class QgsMetadataValidator for validating
metadata against standard schemas.
Initially only QgsNativeMetadataValidator for validating against
the native QGIS metadata schema is implemented.
In future this could be extended with Dublin Core, ISO 19115
validators, etc...
Turns out that there's valid use cases for having layer stores
outside of the cost of using a whole QgsProject.
Partially reverts the merger of QgsMapLayerRegistry into QgsProject,
except that there's no singletons here.
Move all scalebar rendering code out of composer and ensure that
all scalebar rendering is done independant of QgsComposerScaleBar
This allows scalebar rendering code to be reused by plugins
and by non-composer code.
Also rename QgsScaleBarStyle -> QgsScaleBarRenderer, (and all
subclasses too). This name better reflects what these classes do.
Another bit to make core library independent from QgsProject::instance().
Until now labeling engine configuration was taken from project singleton.
Removed legacy methods from QgsPalLabeling - the class now does not have
any more member variables/methods, it is just a bunch of helper functions.
(PR #4384)
QgsRange classes represent a range of values of some element
type. For instance, ranges of QDateTime might be used to
represent the ranges of timestamp ranges.
Ranges can indicate whether the upper and lower values are
inclusive or exclusive. The inclusivity or exclusivity of
bounds is considered when determining things like whether
ranges overlap or during calculation of range intersections.
Includes typedefs for QgsDoubleRange, QgsIntRange, QgsDateRange.
Adds a new geometry class for Triangle geometries
Methods include orthocenter, bisectors, medians, medial, circumscribed (center,
radius), inscribed (center, radius)
Also adds make_triangle expression function for creating triangles
