GitLab

Our current DBus interface exposes all signals, slots and properties of
both MarbleWidget and MarbleMap to the DBus session bus. There are a
couple of problems:
- 3rd party developers who include MarbleWidget have their application
  exposed to DBus and the Marble part of it can be controlled from
  there.
- not all method signatures are compatible with DBus. In particular
  QRegion and Marble specific types cannot be send over DBus (without
  us implementing support for it). In Qt5 there seems to be a change
  that warns against that in the shell. This means that in Qt5 you get
  lots of debug spam all the time in the shell, e.g. a simple map drag
  results in hundreds of warnings a la
    QDBusAbstractAdaptor: Cannot relay signal
Marble::MarbleMap::renderStateChanged(RenderState): Unregistered input
type in parameter list: RenderState
    QDBusAbstractAdaptor: Cannot relay signal
Marble::MarbleWidget::mouseClickGeoPosition(double,double,GeoDataCoordin
ates::Unit): Unregistered input type in parameter list:
GeoDataCoordinates::Unit
    QDBusAbstractAdaptor: Cannot relay signal
Marble::MarbleMap::repaintNeeded(QRegion): Type not registered with
QtDBus in parameter list: QRegion
- it's an utter mess. Currently we expose more than 120 (!) Marble
  specific things to DBus

The patch tries to improve that by
- Not exposing anything to DBus in the library, but only from the Qt
  and KDE applications (i.e. move session bus registration to
  ControlView.cpp)
- Expose only a limited subset of methods and properties (implemented
  in the new class MarbleDBusInterface)

The drawbacks are that we're changing the interface (hence break any
external scripts etc. that rely on it), and limit it at the same time
-- some information that people might be using is not available
anymore. I'm not aware of anyone really using the DBus interface
though, so I'd risk changing it. For limited functionality I'm happy to
bring in more things if there's a sane use case behind it.

REVIEW: 123896

Squashed commit of the kde-frameworks-5 branch, which consisted of
commit 5f8db001 (message repeated below) and some other minor ones.

Affects apps/marble-kde, bindings (not tested), doc, plasmarunner,
plasmoid (deactivated as ktimezonewidget is now gone), thumbcreator.

Also cleans up cmake files: The QTONLY options is gone completely.
KDE parts are only included where necessary, most notably not in
src/lib. Since users might still pass it, QTONLY=TRUE is forwarded
to WITH_KF5=FALSE which matches the old behavior most closely. The new
behavior is better by default however, not erroring out if KF5 is
missing, but instead building Qt parts only.
Additionally the QT5BUILD option is sanitized to behave as originally
planned: You don't have to pass it anymore when both Qt4 and Qt5 are
installed, but cmake figures out which of the two to use and the other
one is disabled (does not interfere anymore).

Compiles without warnings (aside automoc) and without kde4support
libraries. I'm pretty sure however that I broke some parts at runtime
for now, e.g. config saving and installation/loading of some parts.
I18n is not tested as well. Needs to be taken care of in subsequent
commits.

Please report a bug at https://bugs.kde.org/ if this breaks your
build system / compiler for some reason.

See also
https://www.mail-archive.com/marble-devel@kde.org/msg01736.html

(cherry picked from commit bae97d76)

Please report a bug at https://bugs.kde.org/ if this breaks your
build system / compiler for some reason.

See also
https://www.mail-archive.com/marble-devel@kde.org/msg01736.html

(cherry picked from commit 4341e529)

Please report a bug at https://bugs.kde.org/ if this breaks your
build system / compiler for some reason.

See also
https://www.mail-archive.com/marble-devel@kde.org/msg01736.html

(cherry picked from commit e46ddb9c)

Please report a bug at https://bugs.kde.org/ if this breaks your
build system / compiler for some reason.

The plan for now is to use only those C++ 11 features that are
supported by MSVC 10.0 and later.

See also
https://www.mail-archive.com/marble-devel@kde.org/msg01736.html

(cherry picked from commit 250137c8)

To compile with C++ 11, those would need to be changed to
static constexpr with in-class initialization; MSVC 10 however does not
know about constexpr

All public UTM functions are tested with randomly located values whose translation into UTM is known. The functions tested are: utmZone(), utmLatitudeBand(), utmEasting() and utmNorthing().

Improves the solution of the zone labelling bug. Fixes UTM grid. Fixes easting/northing calculation in the poles.

The solution implemented in a18adcfd4d2e7d754b1c030f620b1cd0f92ae245 is moved from renderLongitudeLines() in GraticulePlugin.cpp to the origin of the problem: lonLatToZone() function in GeoDataCoordinates.cpp. The zone labelling bug is no longer found (now, all the fuzzy values such as -114.00000001 are rounded to the nearest integer). Hence, lonLatToZone() function is now completely transparent to the exterior. The calls done from the outside, as from GraticulePlugin.cpp, do not need to shift its calculations to get the correct zone, even with the zone borders, where the bug was found.

The UTM grid showed the zone 31X shifted to the right, while it starts in its standard longitude. This commit fixes this bug with changes in renderUtmExceptions() in GraticulePlugin.cpp

The previous code misbehaved when calculating easting and northing in locations above 84N and below 80S. This commit fixes this bug with changes in lonLatToEasting() and lonLatToNorthing() in GeoDataCoordinates.cpp

The previous code misbehaved when calculating longitude lines labels. Passing the longitude as a qreal to lonToString make that some lines get their zone label wrong (e.g., when passing -114, the function received -114.00000001 and returned the zone associated to [-120,-114[, not the one associated to [-114,-108[; i.e., it returned 11 instead of 12. The current code avoids this problem passing the longitude increased in 3 degrees (i.e., it does not pass the limit of the zone interval but the middle of it)

Reorders GeoDataCoordinates moving all UTM-related code (now separated in four functions) to GeoDataCoordinatesPrivate.

Fixes Nienhüser issue: Move all functions inside GeoDataUTM namespace into GeoDataCoordinatesPrivate.

Fixes Nienhüser issue: Using QPointF insted of qreal vector. Fixes function naming to follow the order lon-lat

Same fix as the one done for the Qt version in commit 4d3cdd74cf5f70c1295e646fb17740d7c14d09da

Adds zone+latitude band to the template position string. Sets fixed precision in the displayed easting/northing values

UTM strings are longer than the longitude/latitude ones. In order to cope with UTM, the maximum width of the field text showing the position in the status bar has been modified, setting the template position string as in UTM mode.
The following restrictions have been taken into account:
The eastings should cover numbers strictly below 1.000.000 (the maximum is around 833,000 m at the equator)
The northings should cover numbers until 10.000.000 (the equator has this northing value seen from the southern hemisphere)
The maximum precision displayed is of 1 cm.