1. 31 Jul, 2016 1 commit
  2. 09 Jun, 2015 1 commit
  3. 01 Jun, 2015 2 commits
    • Dennis Nienhüser's avatar
      302efc0d
    • Dennis Nienhüser's avatar
      Refactoring of the DBus Interface · ac2a7714
      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