[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.
In the style dock there is a new "3D View" tab - so far working just for polygon layers.
It is possible to select a polygon layer, enable 3D renderer and adjust its properties.
If a 3D Map View is open, it will be immediately updated (if auto-apply is enabled)
Very exciting! :-)
setMaximumScale() and setMinimumScale(), maximumScale() and
minimumScale() had the opposite meaning to other min/max scales
in the API, and were the opposite to how these settings were
exposed in the GUI. This lead to very confusing API!!
Their definitions have now been swapped. setMaximumScale
now sets the maximum (i.e. largest scale, or most zoomed in)
at which the layer will appear, and setMinimumScale now sets
the minimum (i.e. smallest scale, or most zoomed out) at
which the layer will appear. The same is true for the
maximumScale and minimumScale getters.
This is necessary in order to be able to correctly translate between absolute and relative paths
deeper in the code - e.g. paths to SVG files used in marker or fill symbols.
Until now, relative paths were translated to absolute paths on the fly.
This is now changed - paths to files should be always absolute within QGIS objects - and paths
only get turned into relative when saving projects. When loading a project, relative paths
are translated to absolute paths immediately.
This should lower the overall confusion about relative/absolute paths within QGIS, and also
allow having different base directories for relative paths (e.g. QML or QPT files may use relative paths
to their directory - rather than to the project directory)
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...
A new class QgsPathResolver is introduced for conversion between absolute
and relative paths when reading/writing XML.
Cleaned up code in layer definition file support (.qlr) to better handle
relative/absolute path conversion.
This allows users to set a timer interval in layer properties
for individual layers. These layers will be automatically refreshed
at a matching interval.
Canvas updates are deferred in order to avoid refreshing multiple
times if more than one layer has an auto update interval set.
Additionally, logic has been added to skip any auto redraws of
the canvas while the canvas is already being redrawn. This avoids
issues caused by setting a layer auto refresh to a shorter time than
is required to redraw the canvas.
By calling QgsMapLayer::triggerRepaint( true ) any cached
version of the layer will be invalidated, but a map canvas
refresh won't automatically be triggered
This allows invalidation of cached images while deferring
the actual map update until the next canvas refresh.
Motivations:
- consistency - we generally use expanded names, and this also
matches Qt API which uses Database instead of Db
- avoids unpredictable capitalization throughout API (mix of "Db"
and "DB")
This allows pieces of code that depend on map layers to listen directly
to the layer's notification rather than having to listen to project's
layersWillBeRemoved signal (and cycle through the whole list)
This allows to declare data dependencies between layers. A data
dependency occurs when a data modification in a layer, not by direct
user manipulation may modify data of other layers.
This is the case for instance when geometry of a layer is updated by a
database trigger after modification of another layer's geometry.
- rename methods with XML to Xml, CRS to Crs, WMS to Wms, ID to Id
- rename methods with SRS to Crs
- rename methods with abbreviations like "dest" to "destination"
- rename methods with abbreviations like "src" to "source"
