QgsNumericFormat subclasses provide a means to format a numeric value
as a string, applying various formatting options. E.g. a default
string to value formatter (included here) includes settings for
controlling the number of decimal places, whether a thousands separator
should be shown, whether a leading + sign should be shown, whether
trailing zeros should be shown.
This PR also includes a formatter for bearings, allowing various
formats of numeric bearings to be applied (e.g. control over decimal
places, etc + control over whether direction E/W suffixes are shown,
or whether values should be limited to either the +/- 180 range or
0-360 degree range)
When formatting values, a QgsNumericFormatContext class is used
to provide context. Currently, this includes the thousands and
decimal separators to apply when formatting (which are taken by
default from the user's locale).
A registry of formatters is included to allow easy addition of
other formats in future (e.g. currencies, percentages, scientific
notation, etc...) and to allow plugin based formats.
The intention is to follow this up with gui configuration widgets
for the formats, and then expose them in various places through
the qgis ui (e.g. in the range editor widget for fields, in scalebar
numbers, as an option for formatting numeric labels, etc)
So that these files are all grouped together, making it easier to locate
all the components of the labeling engine and hopefully making things
easier to navigate
the file was manually added later to the installted headers, but not on mac
it is not possible to install a file in a Headers subfolder within a framework if the original header is not in the same cmake current directory
installing a header in a subdirectory is achieved by setting the MACOSX_PACKAGE_LOCATION property of the source file
but setting a property can only be achieved if it is in the same cmake directory (from the docs: Source file properties are visible only to targets added in the same directory [0])
[0] https://cmake.org/cmake/help/latest/command/set_source_files_properties.html
... you are too slow and QJson API is so ugly.
Now using this wonderful json lib:
https://github.com/nlohmann/json
Results in release mode (QJson tests are not shown but
QJson was even slower than string concat).
PASS : TestQgsJsonUtils::testExportAttributesJson(Use json)
RESULT : TestQgsJsonUtils::testExportAttributesJson():"Use json":
0.0022 msecs per iteration (total: 75, iterations: 32768)
PASS : TestQgsJsonUtils::testExportAttributesJson(Use old string concat)
RESULT : TestQgsJsonUtils::testExportAttributesJson():"Use old string concat":
0.0032 msecs per iteration (total: 54, iterations: 16384)
PASS : TestQgsJsonUtils::testExportFeatureJson(Use json)
RESULT : TestQgsJsonUtils::testExportFeatureJson():"Use json":
0.011 msecs per iteration (total: 96, iterations: 8192)
PASS : TestQgsJsonUtils::testExportFeatureJson(Use old string concat)
RESULT : TestQgsJsonUtils::testExportFeatureJson():"Use old string concat":
0.015 msecs per iteration (total: 64, iterations: 4096)
PASS : TestQgsJsonUtils::testExportGeomToJson(Use json)
RESULT : TestQgsJsonUtils::testExportGeomToJson():"Use json":
0.76 msecs per iteration (total: 98, iterations: 128)
PASS : TestQgsJsonUtils::testExportGeomToJson(Use old string concat)
RESULT : TestQgsJsonUtils::testExportGeomToJson():"Use old string concat":
0.85 msecs per iteration (total: 55, iterations: 64)
PASS : TestQgsJsonUtils::cleanupTestCase()
Similarly to raster calculator, mesh calculator can take dataset groups from current mesh layer and
combine them with various aritmentic/logical operators to new dataset group.
Adds a new interface QgsAbstractValidityCheck which defines
a single "check" which can be performed on a given QgsValidityCheckContext.
A new application-wide QgsValidityCheckRegistry registers
and manages instances of all known checks, and allows running
of all registered checks of a specific type at once.
Initially the framework is focused toward print layout validity
checks, but the interface has been designed to be generic enough
to allow alternative types of validity checks (e.g. project save
validity checks, processing model validity checks, etc.).
The API is designed to be used both by internal validity checks
and also to be extended by custom, organisation-specific
validity checks. E.g., for print layout validity checks we could have:
Causes sip to generate the type hinting stub (".pyi") files
alongside the generated python modules.
This allows editors like PyCharm to become aware of the
types of objects returned by functions, making the autocompletion
much more useful (e.g. by showing all the members available
for a returned type). It also fixes a bunch of incorrect
warnings highlighted in PyCharm for things like calling
static methods in a class (and, generates some new, but valid,
warnings when unexpected types are passed to functions!)
TODO: work out why PyCharm can't show the docstrings
for methods when the pyi file is present.
Introducting MDAL, QgsMeshLayer, mesh data providers (mesh_memory, mdal)
to read and visualize raw meshes: vertices and faces. Support dragging
2dm files from browser on canvas to visualize 2dm meshes.
Support for QgsMeshLayer in Python API.
Switches on the sip "-g" switch, which forces sip to release the
Python Global Interpreter Lock before calling a qgis c++ method,
and reacquire it after.
While this flag is not a default sip flag, it is used when building
the PyQt API, so can't forsee any issues from enabling it.
The benefit however is extreme for PyQGIS based scripts which
rely on threads, potentially resulting in massive performance
boosts.
Without this switch, calling an expensive c++ method (say,
building a QgsSpatialIndex using a QgsFeatureIterator) would lock
the Python GIL for the duration of the c++ call... which could
potentially take minutes or more. With the switch, the lock
is released before all calls, so other Python threads are free
to merrily grab the lock and do other processing while the
original thread chugs away in c++ land.
Benchtests of worst-case scenarios (single thread calling
thousands of very inexpensive PyQGIS methods (simple getters))
regressed from mean of 154 seconds to 158 with this flag. But
that's worst case (and as Intel have recently demonstrated...
we can't take yesterday's computing speed as the benchmark
for todays ;). Given that best case scenarious (multi-threaded
operations calling slow c++ methods) will benefit so greatly
from this change, I think it's an acceptable trade off.
*This is a step toward potentially re-enabling background
execution of python based Processing algorithms, and also
should greatly improve QGIS responsiveness when using
python based renderers/symbols.
