Now the widgets factories can give a score on how good they could handle
a widget.
Additionaly, plugins can be added to choose a widget factory in function
of an external information. One of them uses a table in PostgresQL to
allow specification of the widget type and configuration.
I took the opportunity to remove a few deprecated method in relation to
this.
Now the dialogs use a copy of the ramp, and the edited
ramp is retrieved by calling ramp() on the dialog after
it is executed.
Avoids pointer lifetime issues by storing and working
on a ramp pointer which the dialog does not have ownership
on.
Also fix a bunch of leaks relating to cloning color ramps.
QgsVectorColorRamp -> QgsColorRamp
QgsVectorGradientColorRamp -> QgsGradientColorRamp
QgsRandomColors -> QgsRandomColorRamp
QgsRandomColorRamp -> QgsLimitedRandomColorRamp
QgsVectorColorBrewerColorRamp -> QgsColorBrewerColorRamp
These color ramps are used throughout all of QGIS (not
just in vector symbology) and the current names are
misleading.
* It's now implicitly shared, meaning that changes to the config
can be supervised and a signal is sent from QgsVectorLayer and
there is no risk of elements suddenly being deleted.
* Remove a bunch of methods that were in QgsVectorLayer for legacy
reasons.
QgsMapToolMoveFeature now inherits QgsMapToolAdvancedDigitizing
this allows to specify distance, angles, complex and multiple moves at once
it is now a click and click operation (similarly to the rotate feature map tool): so it can be cancelled once enabled with the right click
* Save more data to QML
* Virtual fields
* Map tips
* Display expression
* Read only flag
* Streamline expression context generation
Whenever an object is able to generate an expression context it
implements the method createExpressionContext() declared in
QgsExpressionContextGenerator.
This makes a cleaner API and allows using QgsFieldExpressionWidget and
QgsDataDefinedButton from python because standard OO programming
approaches are used instead of callbacks and void pointers.
* Colorize output of doc and sip tests
* Fix build
* Fix sip complaints
* Fix rebase problems
* Workaround failing bindings test
Now all evaluate/prepare/etc methods must be called using QgsExpressionContexts
Also remove most remaining traces of special variables. This brings some
user facing changes, such that existing expressions may need to be
updated if they used these old special variables (eg $scale,
$feature). These changes are noted in doc/qgis3_user_changes.dox
so that we can include them in the release notes.
* Remove deprecated Qgis::WKBType and API cleanup
Renames QgsWKBTypes to QgsWkbTypes
Replaces usage of the enums:
* Qgis::WKBType with QgsWkbTypes::Type
* Qgis::GeometryType with QgsWkbTypes::GeometryType
Their values should be forward compatible (a fact that was already
explited up to now by casting between the types)
Renames some SSLxxx to SslXxx and URIxxx to UriXxx
* Fix build warnings and simplify type handling
* Add a fixer to rewrite imports
* The forgotten rebase conflictThe forgotten rebase conflicts
* QgsDataSourcURI > QgsDataSourceUri
* QgsWKBTypes > QgsWkbTypes
* Qgis.WKBGeom > QgsWkbTypes.Geom
* Further python fixes
* Guess what... Qgis::wkbDimensions != QgsWkbTypes::wkbDimensions
* Fix tests
* Python 3 updates
* [travis] pull request caching cannot be disabled
so at least use it in r/w mode
* Fix python3 print in plugins
Previously there was the expressionField (a field name or an expression)
mainly used for the feature list in the form view of the dual view.
On the other hand there was the displayField which could contain either
a simple field name or a complex HTML structure with embedded expressions.
And to know what it was you could compare it's content with the field names, if
a field name matched, you used it as a displayField (original purpose) and
if not... well, you could deal with HTML if you had a use for it.
The main problem is that there are two different usages for this kind of
thing
* plain text identifier (field or expression)
* pretty, rich text feature info
This commit cleans up with this. You want rich text and a lot of info:
go for mapTipTemplate.
You want a plain text string to identify features: go for
the displayExpression.
