DBus interface

[alex-w]

Bug Description

Inter-operability between KStars and Stellarium through DBus.

Copy of email from maillist (https://sourceforge.net/p/stellarium/mailman/message/34798862/): KStars is beginning to expose a lot of functionality through D-Bus, the inter-process communication bus on Linuxy operating systems. I'm not sure how portable it is to Windows, but maybe it is, because the bus itself seems to be fairly lightweight. In any case, it can be made optional.

The advantage that Stellarium as well as KStars have with respect to D-Bus is that Qt makes it really easy to expose functionality on DBus. Qt has a qdbusxml2cpp compiler that turns XML descriptions of a DBus interface into appropriate C++ code seamlessly. Examples of how to create DBus interfaces with Qt are available on, for example, the KDE technical wiki: https://techbase.kde.org/Development/Tutorials/D-Bus/Creating_Interfaces https://techbase.kde.org/Development/Tutorials/D-Bus

The advantage of exposing functionality over DBus is that one can build very powerful scripts in standard scripting languages that combine the abilities of our planetarium software with that of general scripting. For example, in a shell script, these DBus interfaces may be accessed using the qdbus program. Here is an example using qdbus to get KStars to do various things: https://kstars.wordpress.com/2014/01/02/astro-scripting-using-kstars-d-bus-interface/ and here's Jasem's tutorial on how to use python to interface with KStars/INDI through DBus: http://www.indilib.org/support/tutorials/148-dbus-scripting-with-kstars-python.html In fact, with a month of efforts, I was able to create this project that relies heavily on KStars DBus interfaces to produce this: http://bas.org.in/~akarsh/Logbook-Project/

Our previous attempts at inter-operability on this mailing list seemed to center around harder tasks / projects, such as trying to share a code-base, or trying to share a data format or the like. These are more involved tasks, probably why we never got around to them. However, if Stellarium and KStars implement D-Bus methods that are designed to share functionality across the two software, we will be able to provide some amount of inter-operability with minimal code changes and ease.

Immediate examples would be to choose objects from Stellarium and center them in KStars, or vice versa; transfer date/time/geographic location settings across the software; etc. Eventually, we may start exposing the ability to use features that are implemented in one software in the other, reducing effort duplication the easy way. For example, one may eventually be able to invoke KStars' star-hopper in Stellarium, so that a power user could use Stellarium's wonderful interface with KStars' unique backends.

It would be good to eventually have Cartes du Ciel interoperability as well. Cartes exposes functionality through a TCP/IP server. One glue program that translates DBus calls to this TCP/IP server will then allow both KStars and Stellarium to interface with Cartes.

Maybe we should all eventually agree on some standard DBus methods for common functionality such as centering, setting zoom, setting time etc. I am happy to improve DBus interfaces in KStars to enable better interoperability with Stellarium.

The idea at the end of the day is to unite the open source astronomy projects so that we can hope to provide a completely open source astronomy solution for almost all needs. This is especially important for Linux users, who have little access to proprietary software.

Regards Akarsh

Original report

https://bugs.launchpad.net/stellarium/+bug/1562673

[gzotti]

We have a working HTTP RemoteControl plugin, but the module properties can be exposed to DBus as well, which seems even "tighter".