Becuase `represent_value("fieldname")` is much shorter to write and in 98%
there is no need to specify the name separately as
`represent_value("fieldname", 'fieldname')`.
[needs-docs]
In vector layer properties (only usefull for postgres datasources)
**in the rendering tab**
A "Refresh layer on notification" checkbox has been added to refresh layer
on provider notification.
For a postgres datasource, if a `NOTIFY qgis;` command is issued by one of the database clients,
a refresh of the layer will occur.
If the "Only if message is" checkbox is checked, the notification will trigger the refresh only
if the message contend is the one specified, e.g. if the user enters
"refresh" in the box right next to the "Only if message is" checkbox,
then a `NOTIFY qgis, 'refresh';` command in the datatabase will trigger
a layer refresh, but `NOTIFY qgis;` or `NOTIFY qgis, 'something else';`
won't.
**in the actions tab**
A column "On notification" has been added, the action editor widget
a has text field "Execute if notification message matches" to
specify a filter for notification from the provider. The filter is a
Perl-type regex.
Note that, as opposed to the "layer refresh" that
Exemple:
- QGIS side "Execute if notification message matches" `^trigger my action`
- Postgres side: `NOTIFY qgis, 'trigger my action'` will trigger the action
- Postgres side: `NOTIFY qgis, 'trigger my action some additional data'` will trigger the action
- Postgres side: `NOTIFY qgis, 'do not trigger my action some additional data'` will NOT trigger the action
Please note that if the `^`, which means "starts with", in `^trigger my action` had been ommited,
the last notification would have triggered the action because the
notification message contains the `trigger my action`
A new qgis variable `notification_message` is available for use in
actions, it holds the contend of the notification message. To continue
with the previous exemple, if the action is of python type with the code:
```python
print('[% @notification_message %]')
```
The three notifictions above will result in two printed lines
```
trigger my action
trigger my action some additional data
```
User Warning:
For postgres providers, if the "Refresh layer on notification" is checked, or if one layer action has
"On notification" specified, a new connection to the database is made to
listen to postgres notifications. This olds even if transaction groups
are enabled at the project level.
Note that once the notification mechanism is started in a QGIS
session, it will not stop, even if there is no more need for it (Refresh
layer on notification" unchecked and no "On notification" in any
action). Consequently the connection listening to notification will
remain open.
IMPLEMENTATION DETAILS:
A notify signal has been added to the abstract QgsVectorDataProvider
along with a setListening function that enables/disble the notification
mechanism.
For the moment only the postgres provider implements the notification.
QgsAction has a notificationMessage member function that holds the regex
to match to trigger action
QgsActionManager becomes a QObject and is doing the filtering and execute actions on
notifications.
The notification notion extends beyond SRGBD servers (postgres and oracle at
least have the notify) and the "watch file" in the delimitedtext
provider could also benefit from this interface.
For the postgres provider a thread is created with a second connection
to the database. This thread is responsible for listening postgres
notifications.
It would be nice to avoid the creation of one listening chanel per
provider in the case transaction groups are enabled.
Please note that when listening starts (a thread and connection is
created in the postgres provider) it cannot be stopped by removing the
connected actions or unchecking the refresh check box. Indeed, since we
don't know who needs the signals, we dont't want to stop the service.
The service will not restart in the next qgis session though.
If this behavior is not deemed appropriate, we could use
```
int QObject::receivers ( const char * signal ) const
```
and have QgsDataProvider::setListening return a bool to tell the caller
if the signal has actually been closed.
model execution
And use this function to determine in advance dependencies between
child algorithm parameters with expression based values and
which other child algorithms they depend upon.
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.
This adds a new item_variables expression function when expressions
are used inside a composition context.
The function takes a single argument, the id for an item inside
the composition, and returns a map of variable name to value
for that item.
This allows you to do things like insert text in a label fetching
properties of another item in the composition, eg
Insert scale of map into a label:
map_get( item_variables( 'map'),'map_scale')
Insert x coordinate of map center into a label:
x(map_get( item_variables( 'map'),'map_extent_center'))
The order of the elements is irrelevant and duplicate elements are unwanted. It
is therefore a perfect candidate for a set instead of a list. This prevents
filtering for duplicates manually be replacing some filer codes with (more
performant) builtin methods of QSet.
Can be used to store the results of expensive sub-expression
calculations (eg layer aggregates), so that future expression
evaluation using the same context does not have to recalculate
the cached values.
Also improve the API for QgsExpressionContextUtils::updateSymbolScope
Previously it was hard to predict if the method would create storage,
which caused issues for the python bindings (eg, they had a choice of
either leaking or being crashy).
* Move height and angle expressions for 2.5D renderer to layer
* Apply color based on main symbol color
This makes the transition to other renderers easy.
Fixes#14132
During rendering, two new variables will be available:
* `geometry_part_count`
* `geometry_part_num` (1-based index)
Useful to apply different styles to different parts of multipart
features
Now all classes and members are either exposed to bindings or marked
as "not available in Python bindings" in the docs.
Drop test thresholds to 0. Now it should be much easier to determine
what missing members have been added which are causing test
failures.
Rationale:
- there was a lot of large objects passed by value, so potentially
there's a speed bump from this
- even for implicitly shared classes like QString/QList there's still
a (small) cost for copying the objects when there's no reason to
- it's the right thing to do!
