Remove deprecated Qgis::WKBType and API cleanup

[m-kuhn]

Renames QgsWKBTypes to QgsWkbTypes

Replaces usage of the enums:

• Qgis::WKBType with QgsWkbTypes::Type
• Qgis::GeometryType with QgsWkbTypes::GeometryType

Their values should be forward compatible (a fact that was already
explited up to now by casting between the types)

Renames some SSLxxx to SslXxx and URIxxx to UriXxx

[nyalldawson]

Nice! I'm guessing we'll need follow ups here - ie I suspect that layers will not be correctly returning Z/M types until we update the providers to do this?

[m-kuhn]

Yes, we'll need follow ups I guess.
But I think that postgis has already been returning them by just casting to QGis::WKBType and some parts which were aware of that just casted it to the newer equivalent.

[nyalldawson]

My only thoughts - in #3314 it's discussed whether we should move global enums back into the Qgis/QGis/QGIS/qgis/QuantumGIS class, and make it an analog of Qt's "Qt". What do you think?

[m-kuhn]

whether we should move global enums back into the Qgis/QGis/QGIS/qgis/QuantumGIS class

No strong opinion. Qgis.Point is shorter to write than QgsWkbTypes.Point, so that sounds good. Also one less import to do.

One thing is that QGis.Point was for Geometry type (the simple enum with 5 values) whereas the new QgsWkbTypes.Point is for the complex wkb type and the equivalent for the former QGis.Point is QgsWkbTypes.PointGeometry. I wonder if we can somehow prevent this confusion...

[jef-n]

What's the rationale behind collecting all the enums in one header? Doesn't that just cause full rebuilds when a enum changes and separates the enum from where they are used? What are the advantages?

[m-kuhn]

@nyalldawson during rebase I also did some more QGis => Qgis fixes.

I think there are still some removed methods used in the oracle provider...

[nyalldawson]

@jef-n My (incomplete) understanding:

Advantages:

• it's a nicer api, since it avoids the guess work of knowing where a enum sits
• it mirrors Qt's design/structure
• ??

Disadvantages:

• slow recompilation when things change
• mixes everything together
• ??

I was tending towards grouping the common ones, but the more I think about it I think I'm more in favour of keeping them in separate classes. But I'm happy to go either way...

[m-kuhn]

I started to write a fixer for module renames. It's by no means finished, it was probably quite naive to start that on the day before leaving office for a week ;)

[m-kuhn]

Hmmm... I am failing big time with these fixers and there is not much documentation to be found. How did you get that signal magic done, @jef-n ?

[nyalldawson]

What's the rationale behind collecting all the enums in one header? Doesn't that just cause full rebuilds when a enum changes and separates the enum from where they are used? What are the advantages

@jef-n @wonder-sk @m-kuhn can we make a call either way here? Collect enums or not?

[wonder-sk]

I do not not have a strong preference towards any of those options. Happy with whatever others choose.

[m-kuhn]

I do not not have a strong preference towards any of those options. Happy with whatever others choose.

Same here.

[nyalldawson]

@m-kuhn if it's not too much to ask, can you hold off on rebasing this for now? I'm mid-way through a nightmare mega-patch which changes the getters/setters for feature geometry to just QgsGeometry QgsFeature::geometry() const and void QgsFeature::setGeometry( const QgsGeometry& geometry ), and i absolutely dread the thought of merge conflicts with this ;)

[nyalldawson]

@m-kuhn ok, all done here... I'm moving on to other code areas.

[nyalldawson]

Woohoo!!