-
-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Avoid dependency to gui when not needed #66
Comments
Thanks for opening this. Splitting data providers in two modules sounds good to me. I will probably be looking into editor widgets soon. |
I think there was also a problem with QPixmap/QImage introducing a dependency to gui (some room for spliting is probably intoduced because QtWidgets are now separate). Printing/PDF output used to be another (at least on *x). The providers should also be split into "management" and "layer" - ie. create, drop, rename, export, import of tables in one part and the current provider part in the other. The current api to access the first part of the provider functionality is quite clumsy. |
Are you thinking of one "management" provider as backend for several "layer" providers (i.e. "management" corresponds to a database while "layer" corresponds to a table)? I think the most important one is lifting the dependency on the QGIS gui module. Lifting the dependency on QtWidgets would be even better. |
@jef-n yeah avoiding dependencies to an X server would even be better. That means QPixmap and maybe lots of other classes (QFont ? QPrinter ?, etc.) |
Tiny detail: there's a call to QMessageBox in the saveStyle() function of at least Postgre, Spatialite and OGR providers to confirm if an existing style must be overwritten. |
Yes. Currently QgsVectorDataProvider handles one layer (w/ sublayers, but those are IMHO clumsy too) and there is |
@jef-n are you interested in working on this? |
@mhugo an other point: QDialogProgress is used in QgsVectorLayer::countSymbolFeatures qgis/QGIS#2780 |
Anybody knows if tests under ../../tests/src/core/ pass without an X server ? |
They don't. Use |
I think composerlabel/composerhtml |
For server side does-it mean that gui dependencies has been remove ? |
Yes qgis/QGIS#4824 |
Can we close this one? Server now compiles without qgis_gui library, and it is possible to compile providers without select widgets (using WITH_GUI=FALSE cmake option). Removal of dependency of X server in qgis_core is not going to be easy (or even possible? - isn't X server required for text rendering?) - and I am not sure if there is any added value if we did such effort... |
The only thing left on my wish-list is to really decouple provider and provider_gui. While it's in practice possible to compile server without a QtGui dependency, in practice no distribution deploys such binaries because normally the whole stack is created with one set of cmake options and then packaged. |
Some classes depend on the gui part of qgis when it is not needed.
Identified so far :
Ideally, we should also get rid of dependencies to a QtGui components when not needed, and especially when they need an X server :
(original focus: make the server not dependent on a X server anymore)
The text was updated successfully, but these errors were encountered: