I realise this adds another toolbar button... but I'd strongly
argue that the toolbox is used FAR FAR more often than many of the
other toolbar actions!
Avoids incorrect warnings about duplicate shortcuts on startup.
What's happening here is:
- on QGIS startup, plugins are loaded, adding their actions to
the interface via iface.registerMainWindowAction()
- after ALL plugins and qgis native menus and actions are created,
the shortcut manager registers ALL children from the main window.
This includes the actions and widgets created by plugins, which
have already been registered to the manager.
- There's no way to avoid this duplicate registration - we could
move the child shortcut registration to occur before plugin
initialization, but it's actually nice to have this "catch-all"
occur after plugins are loaded (so that plugins which don't
correctly register actions still have them included in the shortcut
manager). Similarly, plugins MUST use the registerMainWindowAction
call instead of just relying on the Qt QAction.setShortcut method
because otherwise the shortcuts manager is unaware of actions
created after QGIS load - e.g. enabling a plugin after startup.
So we avoid this by just refusing to re-register a shortcut
that the manager is already aware of... no more startup warnings!
Brings the behaviour into line with the styling dock, where
the action is checkable and checked only when the toolbox
is open AND user visible (i.e. not hidden behind another tab). If
the toolbox is open but hidden, then hitting the Toolbox action
brings it to the front tab.
Otherwise it's often necessary to hit to Toolbox shortcut twice -
once to close a hidden toolbox tab, and a second time to open
and raise it.
Fixes#17872 - WFS 2.0.0 DescribeFeatureType : TypeNames vs TypeName
This PR introduces the plural form of TYPENAME for
2.0.0 WFS servers, with some additional logic to
allow for 2.0.0 servers that only support TYPENAME
for DescribeFeatureType: in this case, the singular
form is also tried in case the plural one fails.
There is still some work to do for transactional
support but at least the read-only client part
should now be ok.
Tests have been added to check that:
- TYPENAME form still works with old 2.0.0
- TYPENAMES form works with compliant 2.0.0
- choice geometry types are handled by calling
GetFeature and examining the result
Instead of requiring a single layer for use with nested field group
sections, allow use of different layers. In this case the child
layers are filtered so that any fields with names matching their
parent groups are filtered to match the parent section's value.
Also only include headers and footers for child field group sections
if the child has matching features found.
And implement some fixes/improvements (refs discussion on the dev mailing list):
- allow user to specify created field name
- allow optional creation of a summary table showing new class value vs original
value
Child widget was referring to its parent in the destructor - at
this stage the parent may no longer be in a usable state (if the
child's destruction was caused by the parent's destruction)
