-
Dennis Nienhüser authored
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
ac2a7714