[QEP 149] Introduce static data providers #30234
Conversation
PeterPetrik
added
Requires Tests!
tried and it looks like it is not that easy with combination with QFlags. Agreed that will postpone the change until after this PR is merged |
- adds QgsProviderGuiRegistry and QgsProviderGuiMetadata - adds QgsProjectStorageGuiRegistry - requires providerMetadataFactory for dynamic data providers - requires providerMetadataGuiFactory for dynamic data providers (GUI only) - removes QgsProviderRegistry::WidgetMode
- grass data item provider fixes - removed QgsProviderMetadata constructor (with std::function / PyObject) due to sip errors (api break) - reverted DataCapability move to Qgis - back to QgsDataProvider (avoiding api breaks) - WidgetMode enum documentation - sipify monkey patching fix - renamed WidgetMode's "None" to "Normal" value - in python None has special meaning (api break)
|
Regarding the enum, I would like that we use scoped enums since they are much better looking in the Python API. Regarding the equality operator, the question of using an equality sign can be debated since it is quite error prone for flags. |
…ts work again) Also deprecate gui methods in QgsProjectStorage but keep compatibility
In C++ we do not support QgsProviderMetadata(key, description, createFunc) anymore, but for python code we can have a patched class that still supports createFunc. Why not keep the variant with createFunc in C++ as well? Because... SIP! With newly added virtual methods in QgsProviderMetadata, SIP started to generate a sip-specific subclass to handle derived classes in Python, however due to the variant with PyObject* and custom MethodCode it was getting confused about what constructors are available in C++ and failing to compile.
wonder-sk
removed
the
API Break!
wonder-sk
changed the title
|
The pull request should be ready for review & merge. I have done a detailed review of @PeterPetrik 's changes, added some fixes, documentation improvements, reverted some API breaks and polished things a bit. I am now confident the PR is good to go. It would be good to merge this PR soon as the refactoring ended up being huge - much bigger than I anticipated. |
|
I have forgotten to mention that I have also updated the PR description with a summary of changes in the pull request. |
|
Very impressive work! (Also almost completely un-reviewable ;) ) It's the right time of the cycle to merge this kind of change anyway... |
|
Impressive work. |
|
Thanks a lot for taking time to review the code!! ...and apologies again for such monster sized pull request, but it really contains just the minimal amount of changes :-) |
|
Merge away!! |
|
@wonder-sk , @PeterPetrik , I think this broke the AMS provider. I get the following error on any layer I attempt to add to a project:
|
|
And the oracle provider. |
|
AMS provider is fixed 984194b Let me have a look at oracle... |
@wonder-sk I hope you noticed early enough… |
Implementation of QEP: qgis/QGIS-Enhancement-Proposals#149
Sorry for the massive PR, but unfortunately the changes are in handling data providers and it really affect the code all over the place. I tried to not change any logic in the implementations and keep the function in their original location/file where possible. Some exceptions are in
QgsGdalUtilsandQgsOgrUtilswhere the functions are copied from the providers.This work does not make it possible to build data providers as static libraries yet - but we are quite close.
Next steps (followup PRs)
It would be good to think more about the browser model and its data items. Does it make sens to keep QgsBrowserModel in qgis_core? Shouldn't it be in qgis_gui because a lot of functionality of data items is GUI related? (showing message boxes, dialogs, ...) Currently QgsDataItemGuiProvider is there to implement GUI code for data items, but it makes the implementation of data items a bit awkward (split into different areas of code).
A summary of all the major changes follows...
qgis_core
QgsProviderMetadata
QgsProviderRegistry
QgsDataItem
QgsProjectStorage
qgis_gui
QgsProviderGuiMetadata [new]
New interface for data providers for any GUI-related stuff. Currently allows providers to return:
QgsProviderGuiRegistry [new]
New registry for QgsProviderGuiMetadata implementations. To be used through QgsGui::providerGuiRegistry()
QgsProjectStorageGuiProvider [new]
New interface for data providers to implement gui-related functionality related to custom project storage.
QgsProjectStorageGuiRegistry [new]
New registry for QgsProjectStorageGuiProvider implementations. To be used through QgsGui::projectStorageGuiRegistry()
QgsBrowserGuiModel [new]
New class derived from QgsBrowserModel that makes use of QgsDataItemGuiProvider implementations. This class should be used in any gui code instead of QgsBrowserModel (which does not have access to QgsDataItemGuiProvider implementations and thus may not be able to use drag'n'drop of items etc.)
QgsDataItemGuiProvider
Data Provider Interface
Dynamic providers (dll/so) now C-export only 2 functions instead of 10s of functions (isProvider, classFactory, …) that have been replaced by virtual methods in QgsGdalProviderMetadata or QgsGdalGuiProviderMetadata.
gdal and ogr providers
They have been moved to qgis_core and qgis_gui (i.e. those two providers are always present), together with the move they have been properly split into core/gui parts (using data item gui providers, project storage gui providers).