This commit adds a new mode to the attribute table dialog for searching
and filtering features. When activated (using a button on the toolbar
or by pressng CTRL+F), the dialog will switch to form view and all
widgets are replaced with their search widget wrapper variant.
Alongside each widget is a tool button with options for controlling
the search/filter behaviour for that field, eg "equal to", "not equal
to", "is null", "greater than", etc.., with the options presented
matching themselves to the corresponding field and widget type.
New buttons appear at the bottom of the form for either selecting
matching features (with options for add to selection/remove from
selection/select within current selection) or filtering features
in the table (with options for adding features to a current filter
or further restricting a current filter).
Sponsored by SIGE
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.
This adds the possibility to manage data on a normalized relational
database in N:M relations. On the relation editor in a form, the tools
to add, delete, link and unlink work (also) on the linking table if a
relation is visualized as N:M relation.
Configuration is done through the fields tab where on the relation a
second relation can be chosen (if there is a suitable relation in terms
of a second relation on the linking table).
Limitations
===========
QGIS is not a database management system.
It is based on assumptions about the underlying database system. In
particular it expects
* A `ON DELETE CASCADE` or similar measure on the second relation
* Does not take care of setting the primary key when adding features.
Either users need to be instructed to set them manually or - if it's a
database derived value - the layers need to be in transaction mode
(currently only activatable through the API)
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!
If a .ui file is specified and the widget specified in the .ui file is not
supported by the widgetwrapper which is configured in the layer properties
the system will automatically try to find a better suitable widgetwrapper.
To do this, widgetwrappers (respectively their factories) can return a map of
supported widget types with priority values.
The widgetwrapper which offers the heighest priority for a certain widget type
will be used in case of a mismatch.
Sponsored by OPENGIS.ch special projects team (aka gis.se troubleshooting
section)
