[Marble-devel] Review Request 123896: Refactoring of the DBus Interface

[Dennis Nienhüser]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/123896/
-----------------------------------------------------------

(Updated May 25, 2015, 10:51 a.m.)


Review request for Marble.


Changes
-------

added screenshots


Repository: marble


Description (updated)
-------

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,GeoDataCoordinates::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.

The two screenshots show a sketch of the old and the refactored DBus interface.

Refactored DBus Interface:
![Refactored DBus interface (in qdbusviewer)](http://nienhueser.de/marble/marble-dbus-interface-1.png)

Current DBus Interface:
![Current DBus interface (in qdbusviewer)](http://nienhueser.de/marble/marble-dbus-interface-old.png)


Diffs
-----

  src/apps/marble-ui/ControlView.cpp 432c11a 
  src/lib/marble/CMakeLists.txt b52fb1f 
  src/lib/marble/MarbleDBusInterface.h PRE-CREATION 
  src/lib/marble/MarbleDBusInterface.cpp PRE-CREATION 
  src/lib/marble/MarbleMap.cpp 13becfc 
  src/lib/marble/MarbleWidget.cpp f83fcb8 

Diff: https://git.reviewboard.kde.org/r/123896/diff/


Testing
-------

Tested retrieval and changing of all properties/methods using qdbusviewer-qt5. Tested signal emission using dbus-monitor.


Thanks,

Dennis Nienhüser

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/marble-devel/attachments/20150525/3ea85cc1/attachment.html>