QVariant::Type does not exist in PyQt6 as its been deprecated
and replaced with QMetaType::Type.
In order to avoid breaking PyQGIS API, we don't want to change
all our functions to use QMetaType::Type instead of QVariant::Type
(that can wait till QGIS 4.0). So instead we leave the c++/Qt 5
signatures as QVariant::Type, but accept QMetaType::Type values
for these functions under Qt 6 builds.
While QVariant::Type can be directly static_cast to QMetaType::Type,
the reverse is not true and many QMetaType::Type values don't
have exact counterparts in QVariant::Type.
So we use the logic:
- If no conversion is possible, QVariant::UserType will be returned.
Note that we don't use QVariant::Invalid, as the value DOES have
a type, it's just one which needs special handling (just like user
types do)
- Some conversions are lossy, in that the QVariant::Type cannot
represent the full range of values possible in QMetaType::Type.
In these cases the returned type will be an "expanded" type
capable of storing the full range of values possible in the
original type. Eg we map QMetaType::Type::Float to QVariant::Type::Double
QgsVariantUtils::variantTypeToMetaType is included for clarity/
completeness/future proof-ness, even though it currently can
be handled with just a simple static cast.
This ensures that we correctly apply filters to recent projections
too, eg so that a widget showing only vertical crs will ONLY show
recent VERTICAL crs, not every recent crs.
Cleanup QgsProjectionSelectionWidget to use proper models to
drive the combo box. This removes a bunch of very fragile
logic regarding showing and hiding entries on demand, as it
allows us to move all the filtering logic to a single place
in a QSortFilterProxyModel subclass.
This has a few side benefits:
- The combos now dynamically respond to changes like recent
CRS being used in other places in QGIS
- The widget correctly respects horizontal/vertical crs filters
for all entries, including recent crs
Sets whether changes to the active layer should be temporarily
blocked. Exposes a previously private optimisation for use
by plugins.
This is a low-level method, designed to avoid unnecessary work when adding lots
of layers at once. Clients which will be adding many layers may call blockActiveLayerChanges( TRUE ) upfront,
add all the layers, and then follow up with a call to blockActiveLayerChanges( FALSE ). This will defer emitting
the active layer changed signal until they've added all layers, and only emit the signal once for
the final layer added.
The comparisons among QGIS were conducted on coordinates using a fixed epsilon:
specifically, 1e-8 for QgsPoint and the default value for qgsDoubleNear: 4 *
DBL_EPSILON.
Initially, I've standardized its use to 1e-8 universally; it's already
significantly adequate for our Cartesian cases (1e-3 should suffice for many),
potentially fitting just right for geographical contexts.
Furthermore, in response to precision concerns, we're using the fuzzyEqual
and fuzzyDistanceEqual methods. These methods enable users/developers to
compare geometries more easily and with a given precision.
The API remains intact as operator==/equals() have been shifted into fuzzyEqual
(with an epsilon of 1e-8).
To consolidate the code between fuzzyEqual and fuzzyDistanceEqual, helper
functions, fuzzyHelpers, have been introduced following the logic of the
respective segments to be executed.
Adds a new material choice for a physically based metal/roughness
material. Options are available for setting the material base color,
metalness and roughness.
Internally this uses a clone of Qt's QMetalRoughMaterial class. We
use a copy of the Qt class instead of relying on Qt's implementation
as longer-term improvements (such as data defined base color) will
require a re-implementation anyway. By using our own material we
will avoid having two different code paths for the data-defined/
non-data defined scenarios.
