Avoid dependency to gui when not needed

[mhugo]

Some classes depend on the gui part of qgis when it is not needed.

Identified so far :

• Data providers: selectWidget() and similar. Proposition: split each data providers into:
  • the core provider module for a layer
  • the core provider that deals with layer management (deletion, creation as empty, etc.)
  • the module with GUI widgets
• QgsEditorWidgetFactory : all metadata and data access functions of an editor widget should be kept in core only (e.g. QgsEditorWidgetFactory::representValue)
• QgsProject (see https://github.com/qgis/QGIS-Enhancement-Proposals/issues/76)

Ideally, we should also get rid of dependencies to a QtGui components when not needed, and especially when they need an X server :

• Abstract the use of QDialogProgress in core: a base class that outputs to stdout or /dev/null for console application. Found in qgsgml.cpp qgsvectorlayer.cpp qgsvectorlayerimport.cpp and qgsrasterfilewriter.cpp
• QPixmap (X server needed) should be replaced by QImage. Apparently, most of them are introduced by methods that return QIcon. Proposition: modify them to return a QImage (or a QgsIcon that converts to QIcon when needed by the app)

(original focus: make the server not dependent on a X server anymore)

[m-kuhn]

Thanks for opening this.

Splitting data providers in two modules sounds good to me.

I will probably be looking into editor widgets soon.

[jef-n]

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.

[m-kuhn]

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.

[mhugo]

@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.)

[rouault]

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.

[jef-n]

Yes. Currently QgsVectorDataProvider handles one layer (w/ sublayers, but those are IMHO clumsy too) and there is createEmptyLayer, deleteLayer etc. you have to use QLibrary::resolve to get to.

[m-kuhn]

@jef-n are you interested in working on this?

[rldhont]

@mhugo an other point: QDialogProgress is used in QgsVectorLayer::countSymbolFeatures https://github.com/qgis/QGIS/pull/2780

[vmora]

Anybody knows if tests under ../../tests/src/core/ pass without an X server ?

[m-kuhn]

Anybody knows if tests under ../../tests/src/core/ pass without an X server ?

They don't. Use xfvb-run

[mhugo]

@rldhont @rouault thanks for your "tiny" details (!) I've added some more in the ticket description.

Does anybody know why QgsWebView has to be in core ?

[m-kuhn]

Does anybody know why QgsWebView has to be in core ?

I think composerlabel/composerhtml

[rldhont]

For server side does-it mean that gui dependencies has been remove ?

[m-kuhn]

For server side does-it mean that gui dependencies has been remove ?

Yes https://github.com/qgis/QGIS/pull/4824

[wonder-sk]

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...

[m-kuhn]

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.